Addressing Question

[yellowbkpk]

Hi everyone,

I'm looking at some donated street centerline data that has addressing data in the form of "Right/Left From Addr" and "Right/Left To Addr" on each street centerline. Is there an accepted way of applying these tags to the road ways? It doesn't really make very much sense to create and store a separate way just for the addressing information.

...but I might have arrived too late in the argument to say that :-)...

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[andrzej zaborowski]

Hiya,

2009/11/12 Ian Dees <ian.dees@...>:
> I'm looking at some donated street centerline data that has addressing data
> in the form of "Right/Left From Addr" and "Right/Left To Addr" on each
> street centerline. Is there an accepted way of applying these tags to the
> road ways? It doesn't really make very much sense to create and store a
> separate way just for the addressing information.

The hope is that local mappers there will be slowly improving imported
data until there are separate points for every address I think?  Then
I'd recommend just adding those separate ways and making it easier for
the mappers to build on this data, instead of making it harder for
nearly everyone dealing with OSM data by adding a whole different
addressing scheme.

Cheers

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[yellowbkpk]

On Wed, Nov 11, 2009 at 7:55 PM, andrzej zaborowski <balrogg@...> wrote:

Hiya,

2009/11/12 Ian Dees <ian.dees@...>:

> I'm looking at some donated street centerline data that has addressing data
> in the form of "Right/Left From Addr" and "Right/Left To Addr" on each
> street centerline. Is there an accepted way of applying these tags to the
> road ways? It doesn't really make very much sense to create and store a
> separate way just for the addressing information.

The hope is that local mappers there will be slowly improving imported
data until there are separate points for every address I think?  Then
I'd recommend just adding those separate ways and making it easier for
the mappers to build on this data, instead of making it harder for
nearly everyone dealing with OSM data by adding a whole different
addressing scheme.

No, I doubt local mappers will improve the data. I sent this mail because almost all of the data I've seen available for import in the US (all the way from individual municipalities to TIGER's shapefiles) has this left/right-from/to scheme for addressing information.

If the expectation is that we will always be following the Karlsruhe schema (with separate ways on each side of the road centerline), then importing this addressing data will be next to impossible*.

-Ian

* Ok, not "impossible", but the import size would triple and the CPU time to compute the new addressing-only ways might make it hard for the "regular mapper" to do.

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[Anthony-32]

On Wed, Nov 11, 2009 at 9:21 PM, Ian Dees <ian.dees@...> wrote:
> No, I doubt local mappers will improve the data.

If that's true (and I'm really not sure if it is), then it really
shouldn't be in OSM in the first place.

> I sent this mail because
> almost all of the data I've seen available for import in the US (all the way
> from individual municipalities to TIGER's shapefiles) has this
> left/right-from/to scheme for addressing information.
>
> If the expectation is that we will always be following the Karlsruhe schema
> (with separate ways on each side of the road centerline), then importing
> this addressing data will be next to impossible*.

On the other hand, putting the information directly on the way would
be problematic for many reasons.  Ranges might span multiple ways, and
right/left has to be reversed whenever the way is reversed being the
most troublesome.

It probably has to be a relation.  Include a start node, an end node,
and a list of one or more ways (which are connected to form one
logical way).

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[andrzej zaborowski]

2009/11/12 Ian Dees <ian.dees@...>:

> On Wed, Nov 11, 2009 at 7:55 PM, andrzej zaborowski <balrogg@...>
> wrote:
>> The hope is that local mappers there will be slowly improving imported
>> data until there are separate points for every address I think?  Then
>> I'd recommend just adding those separate ways and making it easier for
>> the mappers to build on this data, instead of making it harder for
>> nearly everyone dealing with OSM data by adding a whole different
>> addressing scheme.
>
> No, I doubt local mappers will improve the data. I sent this mail because

That's a pretty pessimistic view.

> almost all of the data I've seen available for import in the US (all the way
> from individual municipalities to TIGER's shapefiles) has this
> left/right-from/to scheme for addressing information.
>
> If the expectation is that we will always be following the Karlsruhe schema
> (with separate ways on each side of the road centerline), then importing
> this addressing data will be next to impossible*.

This would mean we are excluding some features, or some tagging
schemes, in some parts of the world due to disk space or processing
time but not in other parts of the world.  I'm sure we will never have
uniform tagging and uniform data quality everywhere but I still want
to aim at it.

For the record an import I've done had only this left/right - to/from
housenumber information, too, so I have an ugly python script here
ready to throw at this kind of data (after adapting to whatever the
input format is) and I would be happy to do the processing on my PC if
you decide to go this way.  The whole toolchain should still behave
reasonably for data size of TIGER (though obviously I didn't have that
much data)

Cheers

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[yellowbkpk]

On Wed, Nov 11, 2009 at 9:47 PM, andrzej zaborowski <balrogg@...> wrote:

That's a pretty pessimistic view.

Sorry, I am pretty grumpy today. The area I'm looking at actually has quite a few mappers already, so I imagine this data would probably get updated quickly.
 

For the record an import I've done had only this left/right - to/from
housenumber information, too, so I have an ugly python script here
ready to throw at this kind of data (after adapting to whatever the
input format is) and I would be happy to do the processing on my PC if
you decide to go this way.  The whole toolchain should still behave
reasonably for data size of TIGER (though obviously I didn't have that
much data)

What does the math look like to handle intersections? Curvy roads?

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[andrzej zaborowski]

2009/11/12 Ian Dees <ian.dees@...>:
> What does the math look like to handle intersections? Curvy roads?

I admit that data wasn't complex, all segments were straight and all
nodes were treated as intersections.  Do you have parametric (e.g.
bezier) curves or just lots of short segments making soft turns?  (I'm
optimistic we can figure something out in both cases)

Regards

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[Apollinaris Schoell]

On Wed, Nov 11, 2009 at 7:19 PM, Anthony <osm@...> wrote:

On the other hand, putting the information directly on the way would
be problematic for many reasons.  Ranges might span multiple ways, and
right/left has to be reversed whenever the way is reversed being the
most troublesome.

this is enough reason to stay away from such a scheme. if it's too difficult no one will use it or they will break the data.
 

It probably has to be a relation.  Include a start node, an end node,
and a list of one or more ways (which are connected to form one
logical way).

 the ways have to be split at the start/end node. the relation members have to be ordered. too many beginners and medium experienced mappers have problems to understand such a scheme. how is that easier than the Karlsruhe scheme?
 
 

_______________________________________________
Talk-us mailing list
Talk-us@...
http://lists.openstreetmap.org/listinfo/talk-us

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[yellowbkpk]

On Wed, Nov 11, 2009 at 10:17 PM, Apollinaris Schoell <aschoell@...> wrote:

On Wed, Nov 11, 2009 at 7:19 PM, Anthony <osm@...> wrote:

On the other hand, putting the information directly on the way would
be problematic for many reasons.  Ranges might span multiple ways, and
right/left has to be reversed whenever the way is reversed being the
most troublesome.

this is enough reason to stay away from such a scheme. if it's too difficult no one will use it or they will break the data.

This scheme works for all of the places that I'm sourcing data from... they have line segments that are tagged with the left/right-begin/end addresses. Each road is broken up into line segments that have different address values. When this is converted to OSM ways, each way has its address data intact from the source information.

That being said, I do see your point about reversing the order of the way...

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[Marcus Wolschon]

On Thu, Nov 12, 2009 at 2:13 AM, Ian Dees <ian.dees@...> wrote:
> Hi everyone,
>
> I'm looking at some donated street centerline data that has addressing data
> in the form of "Right/Left From Addr" and "Right/Left To Addr" on each
> street centerline.

Can you identify the location of the Addr for the "From/To"?
If so it would be easy to calculate interpolation-ways right
and left of the streets using the Karlsruhe Schema.

> Is there an accepted way of applying these tags to the
> road ways?

No, only in applying it to houses next to the street and special
ways connecting next to the street for interpolating whole
streets of house-numbers at once.

> It doesn't really make very much sense to create and store a
> separate way just for the addressing information.

I disagree here because of the hundrets of special cases
that absolutely must be handled to be correct that come
from the fact that houses are not usually build in the middle
of a road.

> ...but I might have arrived too late in the argument to say that :-)...

Yes, you are. ;)

PS:
I`m not reading the talk-US but as you crossposted there, so do I.
Please let me know of yet another addressing-schema comes
that is in actual usage to make sure my address-search does
work on all the planet.

Marcus

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[Andy Robinson (blackadder-lists)]

Ian Dees wrote:

>Sent: 12 November 2009 1:13 AM
>To: OSM Talk; talk-us@... Openstreetmap
>Subject: [OSM-talk] Addressing Question
>
>Hi everyone,
>
>I'm looking at some donated street centerline data that has addressing data
>in the form of "Right/Left From Addr" and "Right/Left To Addr" on each
>street centerline. Is there an accepted way of applying these tags to the
>road ways? It doesn't really make very much sense to create and store a
>separate way just for the addressing information.
>
>...but I might have arrived too late in the argument to say that :-)...

It doesn't have to conform to any existing scheme. Work out the best way to
import it so that it's of use and that's enough. If it can't be shoehorned
into the Karlsruhe schema that isn't a problem. There will be many places
where one-size-fits-all won't work.

I'd let someone else work out if they can transcribe the data to another
format once its in OSM, should that be desirable

Cheers

Andy



_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[Andy Allan-2]

> Ian Dees wrote:
>>Hi everyone,
>>
>>I'm looking at some donated street centerline data that has addressing data
>>in the form of "Right/Left From Addr" and "Right/Left To Addr" on each
>>street centerline. Is there an accepted way of applying these tags to the
>>road ways? It doesn't really make very much sense to create and store a
>>separate way just for the addressing information.

It's a fairly well established convention that in OSM it's the
houses/plots, not the road centrelines, that are addressed. I'd say
it's better to approximate the gap between the road and the houses
(10m?) than to just put it on the centreline due to that being easier.
This has precedent already - a couple of areas in the US has Karlsruhe
schema addressing converted from what is clearly centreline data to
spread the addresses out on either side:

http://www.openstreetmap.org/?lat=33.676517&lon=-84.012017&zoom=18&layers=B000FTF

Your point about 3 time the number of ways becomes increasing relevant
with the decreasing quality of the data you are importing - 3 times
the headache of fixing dreadful road geometries would be too much!

On Thu, Nov 12, 2009 at 10:42 AM, Andy Robinson (blackadder-lists)
<ajrlists@...> wrote:
> I'd let someone else work out if they can transcribe the data to another
> format once its in OSM, should that be desirable

I disagree there. It's much better to put the effort in during the
initial import, than to import things badly and try to fix it up
later. We've been working on lots of post-import fixups in the last 6
months and it's much harder than everyone assumes. The 4 months to
remove TIGER node tags is a case in point - it took less time than
that to import them!

Cheers,
Andy

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[Apollinaris Schoell]

On 12 Nov 2009, at 6:14 , Andy Allan wrote:

> I disagree there. It's much better to put the effort in during the
> initial import, than to import things badly and try to fix it up
> later. We've been working on lots of post-import fixups in the last 6
> months and it's much harder than everyone assumes. The 4 months to
> remove TIGER node tags is a case in point - it took less time than
> that to import them!
>

+10
Give everyone a chance to work in a constructive way and don't expect  
others to clean the mess bad import left behind.
No wonder there are only few motivated mappers in US. In Canada they  
do a much better job in integrating the community and don't import  
every shape file blindly just because it's available.



> Cheers,
> Andy


_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[yellowbkpk]

On Thu, Nov 12, 2009 at 10:20 AM, Apollinaris Schoell <aschoell@...> wrote:

On 12 Nov 2009, at 6:14 , Andy Allan wrote:

> I disagree there. It's much better to put the effort in during the
> initial import, than to import things badly and try to fix it up
> later. We've been working on lots of post-import fixups in the last 6
> months and it's much harder than everyone assumes. The 4 months to
> remove TIGER node tags is a case in point - it took less time than
> that to import them!
>

+10
Give everyone a chance to work in a constructive way and don't expect
others to clean the mess bad import left behind.
No wonder there are only few motivated mappers in US. In Canada they
do a much better job in integrating the community and don't import
every shape file blindly just because it's available.

Not to start a holy war over what community is better, but there weren't a whole lot of mappers in the US (at least on talk or talk-us) when we started doing the TIGER import...

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[Apollinaris Schoell]

On 12 Nov 2009, at 8:28 , Ian Dees wrote:

> On Thu, Nov 12, 2009 at 10:20 AM, Apollinaris Schoell <aschoell@...
> > wrote:
>
> On 12 Nov 2009, at 6:14 , Andy Allan wrote:
>
> > I disagree there. It's much better to put the effort in during the
> > initial import, than to import things badly and try to fix it up
> > later. We've been working on lots of post-import fixups in the  
> last 6
> > months and it's much harder than everyone assumes. The 4 months to
> > remove TIGER node tags is a case in point - it took less time than
> > that to import them!
> >
>
> +10
> Give everyone a chance to work in a constructive way and don't expect
> others to clean the mess bad import left behind.
> No wonder there are only few motivated mappers in US. In Canada they
> do a much better job in integrating the community and don't import
> every shape file blindly just because it's available.
>
> Not to start a holy war over what community is better, but there  
> weren't a whole lot of mappers in the US (at least on talk or talk-
> us) when we started doing the TIGER import…

It's not about better community. The point is an empty map doesn't  
attract average mappers. someone ambitious needs to start the whole  
thing. A nearly finished map doesn't attract the ambitious mappers. A  
broken map doesn't attract either one.
Imports help with the first challenge. Bad imports not at all.
Tiger import was very useful and done in the best way known at that  
time. but has many problems. technical and community wise.  We  
shouldn't make the same mistakes again just to fill the database.


_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[Dave Hansen-3]

On Thu, 2009-11-12 at 10:28 -0600, Ian Dees wrote:

>        
>         Give everyone a chance to work in a constructive way and don't expect
>         others to clean the mess bad import left behind.
>         No wonder there are only few motivated mappers in US. In Canada they
>         do a much better job in integrating the community and don't import
>         every shape file blindly just because it's available.
>
> Not to start a holy war over what community is better, but there
> weren't a whole lot of mappers in the US (at least on talk or talk-us)
> when we started doing the TIGER import...

People were being actively told not to map in the US because we had
TIGER coming and it would replace any work you ended up doing.

The standard OSM user tries to find their street first.  The typical US
OSM experience has gone from, "My street isn't there" to "My street is
crooked".

-- Dave


_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[Russ Nelson]

Dave Hansen writes:
 > The standard OSM user tries to find their street first.  The typical US
 > OSM experience has gone from, "My street isn't there" to "My street is
 > crooked".

And soon it will go to "My house is in the wrong location".  In
parts of St. Lawrence County, New York, that's already the case:

http://matt.sandbox.cloudmade.com/?lat=44.662793&lng=-74.932251&zoom=11&layer=3

--
--my blog is at    http://blog.russnelson.com
Crynwr supports open source software
521 Pleasant Valley Rd. | [phone]    
Potsdam, NY 13676-3213  |     Sheepdog      

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[Andy Robinson (blackadder-lists)]

Andy Allan [mailto:gravitystorm@...] wrote:

>Sent: 12 November 2009 2:15 PM
>To: Andy Robinson (blackadder-lists)
>Cc: Ian Dees; OSM Talk; talk-us@...
>Subject: Re: [OSM-talk] Addressing Question
>
>> Ian Dees wrote:
>>>Hi everyone,
>>>
>>>I'm looking at some donated street centerline data that has addressing
>data
>>>in the form of "Right/Left From Addr" and "Right/Left To Addr" on each
>>>street centerline. Is there an accepted way of applying these tags to the
>>>road ways? It doesn't really make very much sense to create and store a
>>>separate way just for the addressing information.
>
>It's a fairly well established convention that in OSM it's the
>houses/plots, not the road centrelines, that are addressed. I'd say
>it's better to approximate the gap between the road and the houses
>(10m?) than to just put it on the centreline due to that being easier.
>This has precedent already - a couple of areas in the US has Karlsruhe
>schema addressing converted from what is clearly centreline data to
>spread the addresses out on either side:
>
>http://www.openstreetmap.org/?lat=33.676517&lon=-
>84.012017&zoom=18&layers=B000FTF
>
>Your point about 3 time the number of ways becomes increasing relevant
>with the decreasing quality of the data you are importing - 3 times
>the headache of fixing dreadful road geometries would be too much!
>
>On Thu, Nov 12, 2009 at 10:42 AM, Andy Robinson (blackadder-lists)
><ajrlists@...> wrote:
>> I'd let someone else work out if they can transcribe the data to another
>> format once its in OSM, should that be desirable
>
>I disagree there. It's much better to put the effort in during the
>initial import, than to import things badly and try to fix it up
>later. We've been working on lots of post-import fixups in the last 6
>months and it's much harder than everyone assumes. The 4 months to
>remove TIGER node tags is a case in point - it took less time than
>that to import them!

You make a good point and I certainly wouldn't want to see data imported
that was either difficult to rework or didn't make logical sense. If its
been done before to offset left/right data automagically I too would vote
for that as a preferred import method.

Cheers Andy R



_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[Shalabh-3]

Which somehow reminds of the AND data imported to OSM. I am not sure whether AND and TIGER had anything to do with each other but most of the highways from the AND data in India are straight lines, often a couple of hundred metres off the actual road. I have been deleting old tracks and adding new tracks. Just to give you an example, refer the below frame.

http://www.openstreetmap.org/?lat=32.1488&lon=76.4172&zoom=13&layers=B000FTF

This road, a curvy mountain road was a straight line even at the highest zoom level with no waypoints whatsoever till 2-3 days ago. I have deleted 3 such roads in the last week and replaced with the new ones. And I know there are thousands more to go. I doubt if roads like these actually add any value, either from a mapping or routing point of view to OSM.

Regards,
Shalabh

On Thu, Nov 12, 2009 at 10:47 PM, Andy Robinson (blackadder-lists) <ajrlists@...> wrote:

Andy Allan [mailto:gravitystorm@...] wrote:
>Sent: 12 November 2009 2:15 PM
>To: Andy Robinson (blackadder-lists)
>Cc: Ian Dees; OSM Talk; talk-us@...
>Subject: Re: [OSM-talk] Addressing Question

>
>> Ian Dees wrote:
>>>Hi everyone,
>>>
>>>I'm looking at some donated street centerline data that has addressing
>data
>>>in the form of "Right/Left From Addr" and "Right/Left To Addr" on each
>>>street centerline. Is there an accepted way of applying these tags to the
>>>road ways? It doesn't really make very much sense to create and store a
>>>separate way just for the addressing information.
>
>It's a fairly well established convention that in OSM it's the
>houses/plots, not the road centrelines, that are addressed. I'd say
>it's better to approximate the gap between the road and the houses
>(10m?) than to just put it on the centreline due to that being easier.
>This has precedent already - a couple of areas in the US has Karlsruhe
>schema addressing converted from what is clearly centreline data to
>spread the addresses out on either side:
>
>http://www.openstreetmap.org/?lat=33.676517&lon=-
>84.012017&zoom=18&layers=B000FTF
>
>Your point about 3 time the number of ways becomes increasing relevant
>with the decreasing quality of the data you are importing - 3 times
>the headache of fixing dreadful road geometries would be too much!
>
>On Thu, Nov 12, 2009 at 10:42 AM, Andy Robinson (blackadder-lists)
><ajrlists@...> wrote:
>> I'd let someone else work out if they can transcribe the data to another
>> format once its in OSM, should that be desirable
>
>I disagree there. It's much better to put the effort in during the
>initial import, than to import things badly and try to fix it up
>later. We've been working on lots of post-import fixups in the last 6
>months and it's much harder than everyone assumes. The 4 months to
>remove TIGER node tags is a case in point - it took less time than
>that to import them!

You make a good point and I certainly wouldn't want to see data imported
that was either difficult to rework or didn't make logical sense. If its
been done before to offset left/right data automagically I too would vote
for that as a preferred import method.

Cheers Andy R

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[Anthony-32]

On Wed, Nov 11, 2009 at 11:17 PM, Apollinaris Schoell
<aschoell@...> wrote:
> On Wed, Nov 11, 2009 at 7:19 PM, Anthony <osm@...> wrote:
>> It probably has to be a relation.  Include a start node, an end node,
>> and a list of one or more ways (which are connected to form one
>> logical way).
>>
>  the ways have to be split at the start/end node.

Not if you use a relation.
> the relation members have to be ordered.

No they don't.

> how is that easier than the Karlsruhe scheme?

It's not really easier so much as more correct.

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk