Today, Gerd Petermann wrote: > - wrong data like > * addr:interpolation ways crossing the road > * addr:interpolation ways with nodes that have equal numbers
I don't see any problem with addr:interpolation ways going from the beginning up to the end of a street. If it cause a problem in the renderer, it should be addressed by the renderer developers. For the mapper (surveyor), the address vector is, (in most cases) a linear set of data. If the constraint (addr:interpolation crossing a junction) is removed, then segments can be merged and duplicated addresses will not be a problem anymore. dega Le 28 mars 2015, 08:15:56 talk-ca-requ...@openstreetmap.org a écrit : > Send Talk-ca mailing list submissions to > talk-ca@openstreetmap.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.openstreetmap.org/listinfo/talk-ca > or, via email, send a message with subject or body 'help' to > talk-ca-requ...@openstreetmap.org > > You can reach the person managing the list at > talk-ca-ow...@openstreetmap.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Talk-ca digest..." > > > Today's Topics: > > 1. Re: duplicate address data (Gerd Petermann) > 2. Re: duplicate address data (Stewart C. Russell) > 3. duplicate address data (Gerd Petermann) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 27 Mar 2015 14:51:35 +0100 > From: Gerd Petermann <gpetermann_muenc...@hotmail.com> > To: "talk-ca@openstreetmap.org" <talk-ca@openstreetmap.org> > Subject: Re: [Talk-ca] duplicate address data > Message-ID: <dub112-w68d686608b2188f44c13209e...@phx.gbl> > Content-Type: text/plain; charset="utf-8" > > Hi all, > > I've tried the latest data for Ontario. > I see few errors in data with source NRCan-CanVec-10.0, > but I still see quite a lot of warnings like this: > > http://www.openstreetmap.org/way/176690658 addr:interpolation way connects > two points with equal numbers, numbers are ignored > I also see a lot of messages like this: > found no street for house number element County Road 17 1002 > http://www.openstreetmap.org/node/2009492976 , distance to next possible > road: 9161 m > > I also tried the inspector at http://tools.geofabrik.de/osmi/ > The tools shows a lot of errors, but I fear nobody will spent the time to > investigate an error when he sees > 100 other errors close to it, > and all of them seem to be real errors. > > I agree that the best approach to fix this problem seems to be to remove all > the old data and start from scratch with the latest import data. > > I will not do anything like that, but I think a good approach is to remove > all address data with a tag like > source=CanVec␣6.0␣-␣NRCan > and maybe also > source=NRCan-CanVec-7.0 > > and than see what is missing. > > Gerd > > > Date: Thu, 26 Mar 2015 15:20:36 -0400 > Subject: Re: [Talk-ca] duplicate address data > From: jwhelan0...@gmail.com > To: gpetermann_muenc...@hotmail.com > CC: talk-ca@openstreetmap.org > > Basically the CANVEC data imports need cleaning up. I think there were ten > different versions, the most common I think is 7. Unfortunately some > mappers locally removed the CANVEC tags from the data if they touched it or > even on the import as they didn't think it was important. Sometimes > addresses were imported with a CANVEC tag, sometimes not. Due to funding > cutbacks the CANVEC data is no longer exported in OSM format. > Also there was some original mapping done from low resolution satellites, > Yahoo I think provided the images so some roads were mapped about 100 > meters from where they should be, where highways had been mapped the CANVEC > imports were sometimes used and sometimes not. In Ottawa we took a local > decision to delete all the roads above service roads and replace them with > CANVEC imports because of the data quality issues of the existing road > network and that was some years ago. > Unfortunately in Canada we have fewer mappers per kilometer of highway than > in Germany and the CANVEC imports were very useful. > The clean up solution I would suggest would be to delete all address > information with a CANVEC tag on it then import only CANVEC 10 which is the > latest version but that's a lot of work but the end result would be clean. > It might also hit problems as the address information would follow the > CANVEC highways rather than those highways mapped in other ways but it > would only be the address information and the road network would remain as > it is. > Cheerio John > > On 26 March 2015 at 14:54, Gerd Petermann <gpetermann_muenc...@hotmail.com> > wrote: > > > > Hi list, > > I am one of the developers of mkgmap, see also > http://wiki.openstreetmap.org/wiki/Mkgmap > and > http://gis.19327.n5.nabble.com/Mkgmap-Development-f5324443.html > > During the last weeks I've enhanced the support for > the evaluation of addr:interpolation ways or more general > the evaluation of addr:housenumber, addr:street and so on > to improve the address search in Garmin devices for maps > based on OSM data. > > I live in Germany and I am not very familiar with the address > schemes used in North America. > > It turned out that data in Canada is very special because of the > CanVec imports. I find a huge amount of addr:interpolation > ways that seem to make no sense, often those are > duplicated with identical or nearly identical points > > Example: The ways > http://www.openstreetmap.org/way/99649911 > and > http://www.openstreetmap.org/way/83504524 > > One has source=NRCan-CanVec-7.0, the other source=CanVec 6.0 - NRCan > Is there a good reason for this redundancy? > If not, what is the best way to remove these duplicates? > I can think of different ways: > 1) keep only the eldest entry > 2) keep only the youngest entry > 3) keep the older and add a note that the data is confirmed by > NRCan-CanVec-7.0 > Second problem that occurs very often: > http://gis.19327.n5.nabble.com/weired-housenumbers-in-Canada-tt5835196.html > > The example still exists: > http://www.openstreetmap.org/way/133338396 > A long addr:interpolation way connecting two points which both have > addr:housenumber=5. > If that data is correct, what information does it offer? > I can only guess that along this long way one can find a house with > number 5. Or does it mean that the house is in the middle? > Or is the whole ground along this road "20th Sideroad 5" ? > > And what does it mean when multiple addr:interpolation ways > exist connecting points with equal addr:housenumber, > like here: > http://www.openstreetmap.org/way/133570749#map=18/45.68026/-80.03331&layers= > N Where is Bear Hug Lane 10 and why are there so many addr:interpolations > ways for it? > Any help is welcome. > > Gerd > > P.S. > The program mkgmap in the housenumber2 branch creates a log file that > reports the problem cases in a format like this: "found additional > addr:interpolation way with same meaning, is ignored: 1st Avenue > http://www.openstreetmap.org/way/99649911 127..123, step=2" it would be > easy to change that if needed. > > > > > > > > > > > > > _______________________________________________ > > Talk-ca mailing list > > Talk-ca@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk-ca > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20150327/6742 > 0492/attachment-0001.html> > > ------------------------------ > > Message: 2 > Date: Fri, 27 Mar 2015 22:54:48 -0400 > From: "Stewart C. Russell" <scr...@gmail.com> > To: talk-ca@openstreetmap.org > Subject: Re: [Talk-ca] duplicate address data > Message-ID: <551617f8.6030...@gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Gerd, > > > I've tried the latest data for Ontario. > > Addressing in Canada is a little bit, um, /special/. And I say that as > someone born in the UK, a country famous for its ultra-baroque addressing. > > The important thing I've learned about addresses here is that postal > address ≠ civic address. City addressing is mostly logical, although > with a lot of the municipalities being forcibly amalgamated in 1998, > there are many redundant municipality names/boundaries that /kind of/ > matter in addresses. For example, I live in *Toronto*. If you check > Canada Post's address finder, I live in the (former) Township of > *Scarborough*. My postal code, according to Canada Post and almost > everyone on the planet, is M1K 3N_7_. But my civic address, the one for > which I pay property taxes, has a postal code of M1K 3N_8_. But the City > of Toronto sends that tax bill to M1K 3N7, as Canada Post doesn't agree > with the city. > > [Some bright spark at a vendor I use decided to rationalize all of the > former municipality addresses into the more modern /Toronto/ — and > immediately broke my pre-authorized credit card payments. Seems that the > card was attached to a Scarborough address, which didn't verify against > Toronto, so payments were stopped.] > > Confused yet? Wait until you get to the countryside. There you get > postal addresses which might include a Rural Route number (a mail > delivery route) instead of a street name. There are also County/Township > Route numbers, which are actually street names, but can also have names, > like "Prescott and Russell Road 17", which is County Route 17 on the > border of Prescott & Russell counties. There's yet another address form > in rural areas, which includes the multi-digit 911 number. This is the > emergency services number, and is often given along with the road name. > Canada Post may or may not deliver to a 911 number. And frankly, the > less said about rural postal codes, the better. > > What could be usefully done is stripping out redundant address data > where addresses are clearly inside nested administrative boundaries. > There are a lot of addresses that look like this: > > *<tag k="addr:housenumber" v="1045"/>* > *<tag k="addr:street" v="Pape Avenue"/>* > <tag k="addr:city" v="East York"/> > <tag k="addr:province" v="ON"/> > <tag k="addr:country" v="CA"/> > > > The last three tags are wholly superfluous, and mean that Nominatim > spits out overly long addresses like “1045, Pape Avenue, Thorncliffe > Park, East York, Toronto, Ontario, M4K 3M6, Canada”. > > To one of your interpolation examples: > http://www.openstreetmap.org/node/2009492976 — the end nodes of the > interpolation have "addr:street > <http://wiki.openstreetmap.org/wiki/Key:addr:street?uselang=en-CA> = > County Road 17", but the street itself has "name > <http://wiki.openstreetmap.org/wiki/Key:name?uselang=en-CA> = Prescott > and Russell Road 17". It would be nice if we could interpolate the > nearest parallel(ish) road, rather than needing a name. > > cheers, > Stewart > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20150327/f743 > 0ed7/attachment-0001.html> > > ------------------------------ > > Message: 3 > Date: Sat, 28 Mar 2015 09:15:40 +0100 > From: Gerd Petermann <gpetermann_muenc...@hotmail.com> > To: "talk-ca@openstreetmap.org" <talk-ca@openstreetmap.org> > Subject: [Talk-ca] duplicate address data > Message-ID: <dub112-w119c5989abd0872621545f29e...@phx.gbl> > Content-Type: text/plain; charset="big5" > > > > > Hi Stewart, > > I am not sure what you try to say here. I don't care much about special > cases. My understanding is that the normal scheme in Canada is to have > - odd numbers on one side and even numbers on the other side of a road > (as in Germany) > - numbers seem to be related to distance, one should not expect to find 20 > houses when an addr:interpolation=both way connects two nodes with 1 and > 20 This is also documented here: > http://en.wikipedia.org/wiki/House_numbering#North_America > > In Germany I would expect to find 20 houses or a large building with 20 > different entries. as described here: > http://en.wikipedia.org/wiki/House_numbering#Western_and_Southern_Europe > > I wanted to point out that the OSM data base for Canada contains a huge > amount of - useless data like duplicated addr:interpolation ways > including nodes from different imports which IMHO should be removed ASAP. I > don't know how to automate that process, but I volunteer to help. > > - wrong data like > * addr:interpolation ways crossing the road > * addr:interpolation ways with nodes that refer to a different street > * addr:interpolation ways with nodes that have equal numbers > > Do you suggest that programs using the OSM data should tolerate these > errors and try to guess what is meant? > Of course each programmer can do that, but I think the right way is to try > to have good data in OSM and let programs report the data that is not > plausible. > Gerd > > Hi Gerd, > > > I've tried the latest data for Ontario. > > Addressing in Canada is a little bit, um, /special/. And I say that as > someone born in the UK, a country famous for its ultra-baroque addressing. > > The important thing I've learned about addresses here is that postal > address ≠ civic address. City addressing is mostly logical, although > with a lot of the municipalities being forcibly amalgamated in 1998, > there are many redundant municipality names/boundaries that /kind of/ > matter in addresses. For example, I live in *Toronto*. If you check > Canada Post's address finder, I live in the (former) Township of > *Scarborough*. My postal code, according to Canada Post and almost > everyone on the planet, is M1K 3N_7_. But my civic address, the one for > which I pay property taxes, has a postal code of M1K 3N_8_. But the City > of Toronto sends that tax bill to M1K 3N7, as Canada Post doesn't agree > with the city. > > [Some bright spark at a vendor I use decided to rationalize all of the > former municipality addresses into the more modern /Toronto/ — and > immediately broke my pre-authorized credit card payments. Seems that the > card was attached to a Scarborough address, which didn't verify against > Toronto, so payments were stopped.] > > Confused yet? Wait until you get to the countryside. There you get > postal addresses which might include a Rural Route number (a mail > delivery route) instead of a street name. There are also County/Township > Route numbers, which are actually street names, but can also have names, > like "Prescott and Russell Road 17", which is County Route 17 on the > border of Prescott & Russell counties. There's yet another address form > in rural areas, which includes the multi-digit 911 number. This is the > emergency services number, and is often given along with the road name. > Canada Post may or may not deliver to a 911 number. And frankly, the > less said about rural postal codes, the better. > > What could be usefully done is stripping out redundant address data > where addresses are clearly inside nested administrative boundaries. > There are a lot of addresses that look like this: > > *<tag k="addr:housenumber" v="1045"/>* > *<tag k="addr:street" v="Pape Avenue"/>* > <tag k="addr:city" v="East York"/> > <tag k="addr:province" v="ON"/> > <tag k="addr:country" v="CA"/> > > > The last three tags are wholly superfluous, and mean that Nominatim > spits out overly long addresses like “1045, Pape Avenue, Thorncliffe > Park, East York, Toronto, Ontario, M4K 3M6, Canada”. > > To one of your interpolation examples: > http://www.openstreetmap.org/node/2009492976 — the end nodes of the > interpolation have "addr:street > <http://wiki.openstreetmap.org/wiki/Key:addr:street?uselang=en-CA> = > County Road 17", but the street itself has "name > <http://wiki.openstreetmap.org/wiki/Key:name?uselang=en-CA> = Prescott > and Russell Road 17". It would be nice if we could interpolate the > nearest parallel(ish) road, rather than needing a name. > > cheers, > Stewart > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20150328/3cff > 6eff/attachment.html> > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Talk-ca mailing list > Talk-ca@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-ca > > > ------------------------------ > > End of Talk-ca Digest, Vol 85, Issue 15 > *************************************** _______________________________________________ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
