Re: [OSM-talk] Karlruhe Scheme addressing ways from 2009 TIGER data
Russ Nelson schrieb: Oh, look, we have 99% of all roads in the US in OSM. Can you say that about any other country besides the exceptional Germany and the (dare I say it) imported Netherlands? In German cities we have 90-100% of the roads, but it's not that good in remote rural areas. There are statistics for some areas at http://osm.gt.owl.de/Strassenliste/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Karlruhe Scheme addressing ways from 2009 TIGER data
Dave Hansen wrote: On Mon, 2009-11-16 at 15:05 +, Andy Allan wrote: So please, turn away from imports and work on getting mappers in charge, especially out pounding the streets. The outcome will be much, much better in the end, and that end will come much, much quicker. I think TIGER was a success if only because of all the Europeans we tricked into fixing our roads for us. :) Now if we could do that for the pavement and bicycle signage on Washington's I5... ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Karlruhe Scheme addressing ways from 2009 TIGER data
On Sat, Nov 14, 2009 at 1:40 AM, Mike N. nice...@att.net wrote: tag k=addr:street v=Big Grove Rd / tag k=addr:state v=MyState / tag k=addr:county v=MyCity, ST / tag k=addr:country v=US / I believe people have been saying that this information is not necessary, and is_in is also not necessary for 99% of cases, so we can save space by not including that for the Karlsruhe Schema. (But I don't know how the namefinder works). Yes. Please don't include this point is within such-and-such a polygon data onto the point itself, it's redundant information and not helpful. When a county border is changed by legislation, then moving the border of the county should be sufficient for a mapper. Having to check and update 10,000 address nodes would be error-prone. Adding county/state/country data to address points will lead to a similar problem as we have with the original TIGER node tags - it'll takes ages to remove them further down the line! Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Karlruhe Scheme addressing ways from 2009 TIGER data
2009/11/16 Andy Allan gravityst...@gmail.com Yes. Please don't include this point is within such-and-such a polygon data onto the point itself, it's redundant information and not helpful. When a county border is changed by legislation, then moving the border of the county should be sufficient for a mapper. Having to check and update 10,000 address nodes would be error-prone. +1 is_in is completely useless especially as we improve the polygons like county and administrative areas. I very strongly with Andy here on this topic, especially considering how administrative areas are known to change in different countries. Emilie Laffray ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Karlruhe Scheme addressing ways from 2009 TIGER data
On Nov 14, 2009, at 11:16 AM, Dave Hansen wrote: What really needs to be done for TIGER addresses import is match the streets from TIGER to those in OSM (which should be easy since they all still have the TIGER id's) and generate the address geometry based on these. Otherwise someone will need to do all of the geometry corrections that people have done for this data in the last nearly 2 years. I agree that this is the optimal thing to do. But it's really hard, so I'm not volunteering to take it on. If there's anyone out there braver than I, please speak up. :) I hear you but for the purposes of just thinking about it... I think it might be a lot easier than we think. Forget matching TIGER IDs... if I know a line segment goes from 15th Valencia to 16th Valencia in TIGER then all I need to find in the same set of points in the OSM dataset which isn't going to be super hard. I find 15th, I find Valencia, see if they cross at some node. Same with the other intersection, then see if those nodes are on a way that joins both of them and find the points in between. And as long as the geometry isn't radically different then I can match up the points. I think the major problem would be divided highways where one way is now two ways with different directions, but that shouldn't be super hard to do. Yours c. Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Karlruhe Scheme addressing ways from 2009 TIGER data
Hi, 2009/11/14 SteveC st...@asklater.com: In Denver the houses are all set back a lot further, so some way to say 'on north-south roads, set back X feet' might help a lot. Or, in JOSM just search for all the ways that make up the addressing on one side of the street and move them manually. Many times for each one. I've done a similar import of address data in my area and when writing the converter I forgot to do the projection the first time, this resulted in a similar effect to what you describe. I've not seen Dave's data but looking at the code he's using there's no projection to mercaartor when offsetting the interpolation ways. My ugly code is at http://repo.or.cz/w/ump2osm.git In San Francisco, for divided highways the old TIGER data used to bow in to a point every block and we had, I think, automated ways to split those out in to two straight lines. This is reflected with little bows on the address lines at each intersection - see guerrero for example. What really needs to be done for TIGER addresses import is match the streets from TIGER to those in OSM (which should be easy since they all still have the TIGER id's) and generate the address geometry based on these. Otherwise someone will need to do all of the geometry corrections that people have done for this data in the last nearly 2 years. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Karlruhe Scheme addressing ways from 2009 TIGER data
2009/11/14 andrzej zaborowski balr...@gmail.com: I've done a similar import of address data in my area and when writing the converter I forgot to do the projection the first time, this resulted in a similar effect to what you describe. I've not seen Dave's data but looking at the code he's using there's no projection to mercaartor when offsetting the interpolation ways. On a second look, it's probably correct, it takes the latitude into account when offsetting. One thing I'm missing is for segments that only have a single housenumber for a stretch between two crossings the code should just generate a single node. Currently it either generates the interpolation way with housenumbers at both ends or nothing at all if the segment is too short. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Karlruhe Scheme addressing ways from 2009 TIGER data
On Nov 14, 2009, at 5:49 AM, andrzej zaborowski wrote: Hi, 2009/11/14 SteveC st...@asklater.com: In Denver the houses are all set back a lot further, so some way to say 'on north-south roads, set back X feet' might help a lot. Or, in JOSM just search for all the ways that make up the addressing on one side of the street and move them manually. Many times for each one. I've done a similar import of address data in my area and when writing the converter I forgot to do the projection the first time, this resulted in a similar effect to what you describe. I've not seen Dave's data but looking at the code he's using there's no projection to mercaartor when offsetting the interpolation ways. My ugly code is at http://repo.or.cz/w/ump2osm.git In San Francisco, for divided highways the old TIGER data used to bow in to a point every block and we had, I think, automated ways to split those out in to two straight lines. This is reflected with little bows on the address lines at each intersection - see guerrero for example. What really needs to be done for TIGER addresses import is match the streets from TIGER to those in OSM (which should be easy since they all still have the TIGER id's) and generate the address geometry based on these. Otherwise someone will need to do all of the geometry corrections that people have done for this data in the last nearly 2 years. yeah but that might be non-trivial, whereas I'm happy to go over an entire county budging things Cheers Yours c. Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Karlruhe Scheme addressing ways from 2009 TIGER data
What really needs to be done for TIGER addresses import is match the streets from TIGER to those in OSM (which should be easy since they all still have the TIGER id's) and generate the address geometry based on these. Otherwise someone will need to do all of the geometry corrections that people have done for this data in the last nearly 2 years. matching Tiger id's is a very bad idea. you need to compare geometries. during edits ways are split, merged copied moved, deleted nodes added node, … matching id only a good idea if the way version is 1 and all nodes are version 2 (assuming the attribute cleanup on nodes is finished soon) Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Karlruhe Scheme addressing ways from 2009 TIGER data
2009/11/15 Apollinaris Schoell ascho...@gmail.com: matching Tiger id's is a very bad idea. you need to compare geometries. during edits ways are split, merged copied moved, deleted nodes added node, Most of these operations are not a problem (except copying a whole way to somewhere else), the changed geometry is precisely what we want to detect, so we can't use geometry for matching. I'm sure it has happened that mappers have incorrectly copied the ID to some other way but I really hope that are isolated cases. You claimed people were afraid to touch the Tiger tags. I agree with Anthony that these tags are useless *except* this one tag, the Id *is* useful, please don't remove it. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Karlruhe Scheme addressing ways from 2009 TIGER data
2009/11/15 andrzej zaborowski balr...@gmail.com: I agree with Anthony that these tags are useless *except* this one tag, the Id *is* useful, please don't remove it. To clarify what I mean, a good measure is probably whether you're changing the name on the road. If you're changing the geometry (splitting, merging, whatever) or fixing the spelling or expanding abbrevs, keep the Id. If you're changing the name to a whole different one, remove the id. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Karlruhe Scheme addressing ways from 2009 TIGER data
On 14 Nov 2009, at 18:05 , andrzej zaborowski wrote: 2009/11/15 Apollinaris Schoell ascho...@gmail.com: matching Tiger id's is a very bad idea. you need to compare geometries. during edits ways are split, merged copied moved, deleted nodes added node, Most of these operations are not a problem (except copying a whole way to somewhere else), the changed geometry is precisely what we want to detect, so we can't use geometry for matching. copying is very common for all motorways and other ways with separated lanes. the worst example I have seen was a tiger way copied and used for a piece of coastline. merging is also a big problem because one of the tlid numbers will gone and the other extending in a different area. I'm sure it has happened that mappers have incorrectly copied the ID to some other way but I really hope that are isolated cases. You claimed people were afraid to touch the Tiger tags. I agree with Anthony that these tags are useless *except* this one tag, the Id *is* useful, please don't remove it. yes many of them are useless, I was planning to ask Frederick to extend his bot when he is done with nodes. I think tlid should be kept for reference. some mappers like tiger:reviewed and this should be kept too. zip will be obsolete with address import. county can be derived from county boundaries. not sure about the meaning and usefulness of others Dave knows best why these tags are there and may shed some light on it. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Karlruhe Scheme addressing ways from 2009 TIGER data
On Sat, Nov 14, 2009 at 9:05 PM, andrzej zaborowski balr...@gmail.com wrote: I agree with Anthony that these tags are useless *except* this one tag, the Id *is* useful, please don't remove it. What's useful about it? Or to ask the question a different way, what is the tag supposed to mean? On Sat, Nov 14, 2009 at 9:11 PM, andrzej zaborowski balr...@gmail.com wrote: To clarify what I mean, a good measure is probably whether you're changing the name on the road. If you're changing the geometry (splitting, merging, whatever) or fixing the spelling or expanding abbrevs, keep the Id. If you're changing the name to a whole different one, remove the id. There must be a better way to compare the name of a road than counting on all the editors to copy/preserve the tiger id. When you merge two TIGER ways which id do you keep? Or should you keep them both (separated by a semicolon)? Where is this documented? Unless you can point me to some documentation as to what the tiger id *means* (*), I'm not going to think about it at all. Sometimes I keep it, sometimes I delete it, sometimes I delete the whole way and create a new one in its place (without any of the tiger tags). And I'm sure I'm not the only one. (*) I take it to mean simply that the originally imported way came from a certain TIGER way, which is preserved in the way history ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Karlruhe Scheme addressing ways from 2009 TIGER data
2009/11/15 Apollinaris Schoell ascho...@gmail.com: copying is very common for all motorways and other ways with separated lanes. And this is ok too, it means that both these ways in TIGER are one way with the given Id, this is just the information any automated process will be looking for. the worst example I have seen was a tiger way copied and used for a piece of coastline. Well this isn't ok :) Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Karlruhe Scheme addressing ways from 2009 TIGER data
2009/11/15 Anthony o...@inbox.org: On Sat, Nov 14, 2009 at 9:05 PM, andrzej zaborowski balr...@gmail.com wrote: I agree with Anthony that these tags are useless *except* this one tag, the Id *is* useful, please don't remove it. What's useful about it? Or to ask the question a different way, what is the tag supposed to mean? It means that this way's Id in that other dataset there is XYZ. Hopefully we will soon have a better dataset and more keeping-up-to-date-power than that dataset and it will be up to them to keep up with us, for now they have more current data and if we ever want to bulk update our data we will need this info. Also, maybe I'm too excited about this idea called Linked Data ([1]), but even even if we don't want to update, I think it's a piece of info that isn't found anywhere else and would be cool to keep. When you merge two TIGER ways which id do you keep? Or should you keep them both (separated by a semicolon)? The one from which you take the name or whatever logically preserves the identity. (Possibly none) Cheers 1. http://en.wikipedia.org/wiki/Linked_Data ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Karlruhe Scheme addressing ways from 2009 TIGER data
Can I have SF county, CA please and Arapahoe County, CO...? Yours c. Steve On Nov 13, 2009, at 4:57 PM, Dave Hansen wrote: So, just like the original TIGER import, I'm now grossly stealing someone else's code: http://svn.openstreetmap.org/applications/utils/import/tiger2osm/shape_to_osm-Tiger.py and I now have made some .osm files with Karlruhe Scheme addressing ways. I'm not going to post them publicly. I did that for the original TIGER, and some enterprising folks took them and uploaded without mentioning it to anyone and it turned into a big mess with no coordination. If anyone wants to see the data for their county, let me know. I'll send you a copy of what I have. All you have to do is convince me that you'll never upload these initial data under any circumstances. :) We'll work on making sure that these data look good and I think some people have some plans on how to get these integrated a bit at a time. -- Dave ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Karlruhe Scheme addressing ways from 2009 TIGER data
http://svn.openstreetmap.org/applications/utils/import/tiger2osm/shape_to_osm-Tiger.py We'll work on making sure that these data look good and I think some people have some plans on how to get these integrated a bit at a time. Thanks to those who worked on the namefinder - it worked GREAT when I tried it today. (THANKS to those who created the new namefinder!) It properly identified my house by Hamlet, City, County, etc without my including any of that information in the house number or street.With that in mind, the script tags everything with: tag k=addr:street v=Big Grove Rd / tag k=addr:state v=MyState / tag k=addr:county v=MyCity, ST / tag k=addr:country v=US / I believe people have been saying that this information is not necessary, and is_in is also not necessary for 99% of cases, so we can save space by not including that for the Karlsruhe Schema. (But I don't know how the namefinder works). ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Karlruhe Scheme addressing ways from 2009 TIGER data
Dave I've looked at the two you sent me and they're both basically fine but for two things. In Denver the houses are all set back a lot further, so some way to say 'on north-south roads, set back X feet' might help a lot. Or, in JOSM just search for all the ways that make up the addressing on one side of the street and move them manually. Many times for each one. In San Francisco, for divided highways the old TIGER data used to bow in to a point every block and we had, I think, automated ways to split those out in to two straight lines. This is reflected with little bows on the address lines at each intersection - see guerrero for example. Otherwise looks good to me! What are your plans? Yours c. Steve On Nov 13, 2009, at 4:57 PM, Dave Hansen wrote: So, just like the original TIGER import, I'm now grossly stealing someone else's code: http://svn.openstreetmap.org/applications/utils/import/tiger2osm/shape_to_osm-Tiger.py and I now have made some .osm files with Karlruhe Scheme addressing ways. I'm not going to post them publicly. I did that for the original TIGER, and some enterprising folks took them and uploaded without mentioning it to anyone and it turned into a big mess with no coordination. If anyone wants to see the data for their county, let me know. I'll send you a copy of what I have. All you have to do is convince me that you'll never upload these initial data under any circumstances. :) We'll work on making sure that these data look good and I think some people have some plans on how to get these integrated a bit at a time. -- Dave ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
