Re: [Talk-ca] duplicate address data
Hi Paul, up to now I did not edit much data in OSM, esp. I've never done a mass update. My idea is to create a list of identical objects which could be removed without losing information. Something like duplicate addr:interpplation way I wonder why nobody has coded a bot for this? Gerd To: gpetermann_muenc...@hotmail.com CC: talk-ca@openstreetmap.org From: penor...@mac.com Subject: Re: [Talk-ca] duplicate address data Date: Thu, 26 Mar 2015 19:38:48 + On Mar 26, 2015, at 11:55 AM, Gerd Petermann wrote: 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 This is a case where someone imported CanVec improperly without resolving conflicts with existing data. If both interpolation ways are the same, it doesn't matter which is deleted. You could investigate the changeset the more recent one came from and see if the entire thing needs reverting. If they differ, look to see if one has been edited and keep that one. If neither have been edited, I'd presume CanVec 7 to be more accurate than CanVec 6 in absence of any other information.___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] duplicate address data
The Geofabrik address validator (http://tools.geofabrik.de/osmi/), click Addresses, is useful for finding these address bugs. There are a lot of these in Canada. Also there are a lot of roads where the road name on the road does not match the road name from the address data, in this case a survey is needed to figure out which of the two names (or neither of them) is correct. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] duplicate address data
Hi John, thanks for the quick feedback. I can try that by adding some rules to mkgmap so that it ignores data with source=CANVEC* that is not like CANVEC 10 . If I got you right I should only find a a few error messages. If that turns out to be correct, I'll try to learn more about the imports. Ciao, 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 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/18396 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 ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] duplicate address data
On Mar 26, 2015, at 11:55 AM, Gerd Petermann wrote: 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 This is a case where someone imported CanVec improperly without resolving conflicts with existing data. If both interpolation ways are the same, it doesn't matter which is deleted. You could investigate the changeset the more recent one came from and see if the entire thing needs reverting. If they differ, look to see if one has been edited and keep that one. If neither have been edited, I'd presume CanVec 7 to be more accurate than CanVec 6 in absence of any other information.___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] duplicate address data
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 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/18396 > 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 > > ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] duplicate address data
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/18396 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
Re: [Talk-ca] Business incubator
Thanx Richard and Tom. I'm happy the search will reveal an item that does not show in the rendered map but I still find it awkward that the name of a container business can't be rendered if we logically assign the attribute name to a polygon. I'll do what you both suggest since there doesn't seem to be another way, but IMO it doesn't meet the use case of someone searching for "Shopping Mall X" or some other container object, is redirected to the right location on the map only to see no evidence of the sought name in the renderer at all. I would expect to see the name of the container at small scales (zoomed out) and then individual shops as one zooms in. When individual shop names start to show up, I would expect the name of the container to still show up in a slightly larger font so it's clear for people that those shops are in that shopping center. Oddly enough, in the case of Tom's link, zooming in one more level showed the Heron Gate Mall name. Not the case for Jamieson Estate Plaza though. My 2 cents; cheers, Yves On Thu, Mar 26, 2015 at 12:53 PM, Yves Moisan wrote: Hi Richard ! Thanx for your answer. OK to tag addr.* to the building outline and remove them from the building symbol. Still, I'd like to see an obvious point mark for the incubator on the map. For now, I resort to a building point feature but it would be neat if there were some generic "commercial" or "business" symbol. Otherwise, the map will show point features for individual constituent businesses in the incubator, but not the incubator itself, which bugs me. You say you do the same for shopping marts. Do you have an example I could look at ? I would expect to see "Shopping Center XYZ" alongside the consitituent shops on the map. So if there's a way to avoid having a point symbol to highlight the container name on the map, I'm all for it. Searching for Jamieson Estate Plaza, We find : http://www.openstreetmap.org/way/31725282#map=19/43.42331/-80.28583 So, even though the name of the container-building isn't rendered in this specific renderer we find the right data, without surprising duplicates. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Business incubator
On Thu, Mar 26, 2015 at 12:53 PM, Yves Moisan wrote: > Hi Richard ! > > Thanx for your answer. OK to tag addr.* to the building outline and remove > them from the building symbol. Still, I'd like to see an obvious point mark > for the incubator on the map. For now, I resort to a building point feature > but it would be neat if there were some generic "commercial" or "business" > symbol. Otherwise, the map will show point features for individual > constituent businesses in the incubator, but not the incubator itself, which > bugs me. > > You say you do the same for shopping marts. Do you have an example I could > look at ? I would expect to see "Shopping Center XYZ" alongside the > consitituent shops on the map. So if there's a way to avoid having a point > symbol to highlight the container name on the map, I'm all for it. Searching for Jamieson Estate Plaza, We find : http://www.openstreetmap.org/way/31725282#map=19/43.42331/-80.28583 So, even though the name of the container-building isn't rendered in this specific renderer we find the right data, without surprising duplicates. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Business incubator
building=commercial on the building outline for a start. My own practice is to add point mappings for shops. Forr a rendered view you can see my local shopping centre at http://www.openstreetmap.org/#map=17/45.37936/-75.64383 Tom Taylor tomt5454 On 26/03/2015 12:53 PM, Yves Moisan wrote: Hi Richard ! Thanx for your answer. OK to tag addr.* to the building outline and remove them from the building symbol. Still, I'd like to see an obvious point mark for the incubator on the map. For now, I resort to a building point feature but it would be neat if there were some generic "commercial" or "business" symbol. Otherwise, the map will show point features for individual constituent businesses in the incubator, but not the incubator itself, which bugs me. You say you do the same for shopping marts. Do you have an example I could look at ? I would expect to see "Shopping Center XYZ" alongside the consitituent shops on the map. So if there's a way to avoid having a point symbol to highlight the container name on the map, I'm all for it. I know it's a bit of "mapping for the renderer" but I feel it's an issue. Thanx for your help and cheers, Yves Hi Yves! On Thu, Mar 26, 2015 at 10:57 AM, Yves Moisan wrote: Folks, Our old police station was turned into a business incubator : [ ... ] 2) I added the addr:* info to the point symbol, not the building outline (canvec import). I'm thinking the addr.* info really belongs to the building, as that's the only thing with a street address (with maybe I agree. Address information generally applied to the building. The current building-polygon, with a contained building-point is an unusual construction. I would expect only one database item for the building. Either the point OR the polygon, but not both. Case in point : there are close to ten businesses in there now, one being a DIY shop that I would really like to map. So should I name the building outline with the name of the incubator (the container) and remove the point symbol altogether, then add point symbols only for the constituent businesses that are hosted in the incubator? That sounds great. i use the same concept in mapping small shopping areas, where one building contains a row of retail stores. Address on the containing building polygon, then several shop=something / name=SomeThing points as appropriate. Best regards and happy mapping, Richard ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Business incubator
Hi Richard ! Thanx for your answer. OK to tag addr.* to the building outline and remove them from the building symbol. Still, I'd like to see an obvious point mark for the incubator on the map. For now, I resort to a building point feature but it would be neat if there were some generic "commercial" or "business" symbol. Otherwise, the map will show point features for individual constituent businesses in the incubator, but not the incubator itself, which bugs me. You say you do the same for shopping marts. Do you have an example I could look at ? I would expect to see "Shopping Center XYZ" alongside the consitituent shops on the map. So if there's a way to avoid having a point symbol to highlight the container name on the map, I'm all for it. I know it's a bit of "mapping for the renderer" but I feel it's an issue. Thanx for your help and cheers, Yves Hi Yves! On Thu, Mar 26, 2015 at 10:57 AM, Yves Moisan wrote: Folks, Our old police station was turned into a business incubator : [ ... ] 2) I added the addr:* info to the point symbol, not the building outline (canvec import). I'm thinking the addr.* info really belongs to the building, as that's the only thing with a street address (with maybe I agree. Address information generally applied to the building. The current building-polygon, with a contained building-point is an unusual construction. I would expect only one database item for the building. Either the point OR the polygon, but not both. Case in point : there are close to ten businesses in there now, one being a DIY shop that I would really like to map. So should I name the building outline with the name of the incubator (the container) and remove the point symbol altogether, then add point symbols only for the constituent businesses that are hosted in the incubator? That sounds great. i use the same concept in mapping small shopping areas, where one building contains a row of retail stores. Address on the containing building polygon, then several shop=something / name=SomeThing points as appropriate. Best regards and happy mapping, Richard ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Business incubator
Hi Yves! On Thu, Mar 26, 2015 at 10:57 AM, Yves Moisan wrote: > Folks, > > Our old police station was turned into a business incubator : [ ... ] > 2) I added the addr:* info to the point symbol, not the building outline > (canvec import). I'm thinking the addr.* info really belongs to the > building, as that's the only thing with a street address (with maybe I agree. Address information generally applied to the building. The current building-polygon, with a contained building-point is an unusual construction. I would expect only one database item for the building. Either the point OR the polygon, but not both. > Case in point : there are close to ten businesses in there now, one being a > DIY shop that I would really like to map. So should I name the building > outline with the name of the incubator (the container) and remove the point > symbol altogether, then add point symbols only for the constituent > businesses that are hosted in the incubator? That sounds great. i use the same concept in mapping small shopping areas, where one building contains a row of retail stores. Address on the containing building polygon, then several shop=something / name=SomeThing points as appropriate. Best regards and happy mapping, Richard ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Business incubator
Folks, Our old police station was turned into a business incubator : http://osm.org/go/cKDjq9KKi?node=1947683551. It was inaugurated yesterday and it's new name was officialized : http://www.lapresse.ca/la-tribune/economie-et-innovation/201503/26/01-4855585-le-400-rue-marquette-devient-lespace-inc-une-grande-journee-pour-notre-economie.php. I changed the underlying building from "Police station" to "building" last week. I also added a "building" point feature, short of having something in Potlatch-2 choices even remotely reminiscent of a business center of sorts with the name I had last week, then just updated it now with the new name. I'm not happy with the results and I'm looking for ways to improve. I have two questions : 1) What tag could I use for my incubator point feature ? Isn't there some generic "business" point symbol somewhere ? The closest I found is shopping/DIY (and that kind of applies since there is a real DIY shop in there too) but the incubator really is a kind of coworking place, a container for other businesses 2) I added the addr:* info to the point symbol, not the building outline (canvec import). I'm thinking the addr.* info really belongs to the building, as that's the only thing with a street address (with maybe indidivual shops having some internal address designation but definitely not a separate civic address) but I put the address info in the point feature just to be sure it would be searchable. Could I rely on the geosearch (and router) finding a point target without address info because it would be clever enough to look at the layer "underneath" (in my case the building outline) ? Do I have to duplicate the information (which I definitely would like to avoid) ? Case in point : there are close to ten businesses in there now, one being a DIY shop that I would really like to map. So should I name the building outline with the name of the incubator (the container) and remove the point symbol altogether, then add point symbols only for the constituent businesses that are hosted in the incubator? Or should I keep the point symbol for the container (incubator) too ? Thanx for pointers, Yves ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Target Canada
Added the one we have in Sherbrooke, Qc both in the wiki and map. It's supposed to close on April 1, but I'll wait and see if it really happens, given the date. Yves ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
