Re: [OSM-talk-be] POI Address problem
Processing addresses in my opinion has to be smart enough to handle all this. When I process OSM-data for mobile devices everything is removed that is not useful and I would hope other software is also smart enough to keep only the data it needs. I don't know of any mobile app that consumes OSM-data in it's raw form, except maybe some of the mobile editors. Mostly the arguments in favor of the associatedStreet relation are related to technology, the arguments against are the fact that OSM is more than a collection of hackers trying to build a map. These technology arguments are things that can be solved either way and I think we have enough people that can do this kind of stuff. The thing we really need are more mappers and I don't think OSM should become the kind of project where you would have to be an 'expert' to add a simple address to the database. Met vriendelijke groeten, Best regards, Ben Abelshausen ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] POI Address problem
I'll rest my case for the associatedStreet relation. I was indeed talking about mobile editors like Vespucci or iLoE, not something like OsmAND, which does preprocess the data. I won't stop adding them myself every once in a while, but that won't change much, as adresses are not what I'm concentrating on, even though they are, of course, important. To be able to keep things workable once all those adresses will be added, I'll find a way to purge them from the dataset locally after each download... Can't live without autosave, but it's annoying it interrupts the workflow for longer and longer amounts of time. My preference is to do things in an efficient way, but we don't do that for other things either. Jo 2013/11/18 Ben Abelshausen ben.abelshau...@gmail.com Processing addresses in my opinion has to be smart enough to handle all this. When I process OSM-data for mobile devices everything is removed that is not useful and I would hope other software is also smart enough to keep only the data it needs. I don't know of any mobile app that consumes OSM-data in it's raw form, except maybe some of the mobile editors. Mostly the arguments in favor of the associatedStreet relation are related to technology, the arguments against are the fact that OSM is more than a collection of hackers trying to build a map. These technology arguments are things that can be solved either way and I think we have enough people that can do this kind of stuff. The thing we really need are more mappers and I don't think OSM should become the kind of project where you would have to be an 'expert' to add a simple address to the database. Met vriendelijke groeten, Best regards, Ben Abelshausen ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] POI Address problem
I'm using autosave as well, don't see the problems that you encounter. Perhaps you have much larger changesets ? :-) Does autosave write everything ? Or only the things that are changed ? Just curious to pinpoint the exact cause of the long autosaves you encounter. m On Mon, Nov 18, 2013 at 12:39 PM, Jo winfi...@gmail.com wrote: I'll rest my case for the associatedStreet relation. I was indeed talking about mobile editors like Vespucci or iLoE, not something like OsmAND, which does preprocess the data. I won't stop adding them myself every once in a while, but that won't change much, as adresses are not what I'm concentrating on, even though they are, of course, important. To be able to keep things workable once all those adresses will be added, I'll find a way to purge them from the dataset locally after each download... Can't live without autosave, but it's annoying it interrupts the workflow for longer and longer amounts of time. My preference is to do things in an efficient way, but we don't do that for other things either. Jo 2013/11/18 Ben Abelshausen ben.abelshau...@gmail.com Processing addresses in my opinion has to be smart enough to handle all this. When I process OSM-data for mobile devices everything is removed that is not useful and I would hope other software is also smart enough to keep only the data it needs. I don't know of any mobile app that consumes OSM-data in it's raw form, except maybe some of the mobile editors. Mostly the arguments in favor of the associatedStreet relation are related to technology, the arguments against are the fact that OSM is more than a collection of hackers trying to build a map. These technology arguments are things that can be solved either way and I think we have enough people that can do this kind of stuff. The thing we really need are more mappers and I don't think OSM should become the kind of project where you would have to be an 'expert' to add a simple address to the database. Met vriendelijke groeten, Best regards, Ben Abelshausen ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] POI Address problem
The areas I'm working with are very large (for the bus routes). Now the autosaves take 15-20 seconds (on SSD). That will change when all the adresses will have been added. But maybe it will change anyway. AS relations or not. I'll find a solution, no problem. The problem is rather that when all the addresses in say Europe will have been added and we're not careful with diskspace, it will have become impossible for people like you and me to work with all that data as a whole. But, as I said, I was going to rest my case. Jo 2013/11/18 Marc Gemis marc.ge...@gmail.com I'm using autosave as well, don't see the problems that you encounter. Perhaps you have much larger changesets ? :-) Does autosave write everything ? Or only the things that are changed ? Just curious to pinpoint the exact cause of the long autosaves you encounter. m On Mon, Nov 18, 2013 at 12:39 PM, Jo winfi...@gmail.com wrote: I'll rest my case for the associatedStreet relation. I was indeed talking about mobile editors like Vespucci or iLoE, not something like OsmAND, which does preprocess the data. I won't stop adding them myself every once in a while, but that won't change much, as adresses are not what I'm concentrating on, even though they are, of course, important. To be able to keep things workable once all those adresses will be added, I'll find a way to purge them from the dataset locally after each download... Can't live without autosave, but it's annoying it interrupts the workflow for longer and longer amounts of time. My preference is to do things in an efficient way, but we don't do that for other things either. Jo 2013/11/18 Ben Abelshausen ben.abelshau...@gmail.com Processing addresses in my opinion has to be smart enough to handle all this. When I process OSM-data for mobile devices everything is removed that is not useful and I would hope other software is also smart enough to keep only the data it needs. I don't know of any mobile app that consumes OSM-data in it's raw form, except maybe some of the mobile editors. Mostly the arguments in favor of the associatedStreet relation are related to technology, the arguments against are the fact that OSM is more than a collection of hackers trying to build a map. These technology arguments are things that can be solved either way and I think we have enough people that can do this kind of stuff. The thing we really need are more mappers and I don't think OSM should become the kind of project where you would have to be an 'expert' to add a simple address to the database. Met vriendelijke groeten, Best regards, Ben Abelshausen ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] POI Address problem
Got this answer from lonvia on help.osm.org You've mapped it correctly, Nominatim is just not very good at updating associatedStreet relations. It's a known bughttps://trac.openstreetmap.org/ticket/4619 . Here is what happened: you've originally put the house into this associatedStreet relationhttp://www.openstreetmap.org/browse/relation/2594673 which does contain the 'Pierstraat - Matenstraat' street. Nominatim simply uses the first street it finds in such a relation for the name an ignores all tags on the relation itself, so that is where the name comes from. Later you have moved the house to the new relation and that move was not caught by Nominatim's update process. The houses will only be updated when they are changed themselves again. also interesting is this quote from lonvia in the above mentioned bug: Nominatim would be perfectly happy if you added only addr:street tags and got rid of the associatedStreet relations. The relations mostly don't carry any additional information and are a bit of a pain to handle. addr:street is much better supported. So I wonder more and more whether we should add those theoretically nice associatedStreet relations On Thu, Nov 14, 2013 at 1:10 PM, Marc Gemis marc.ge...@gmail.com wrote: the help thread is here: https://help.openstreetmap.org/questions/28075/how-to-correctly-map-a-pois-address seems that Nominatim was not updated after the associatedStreet-relation update On Thu, Nov 14, 2013 at 10:50 AM, Marc Gemis marc.ge...@gmail.com wrote: I'm reading http://wiki.openstreetmap.org/wiki/Nominatim/Development_overview again, especially the section on Building indexing Buildings, houses and other lower than street level features (i.e., bus stops, phone boxes, etc.) are indexed by relating them to their most appropriate nearby street. The street is calculated as: 1. The street member of an associatedStreet relation 2. If the node is part of a way: 2.1 If this way is street level, than that street 2.2 The street member of an associatedStreet relation that this way is in 2.3 A street way with 50/100 meters and parallel with the way we are in 3. A nearby street with the name given in addr:street of the feature we are in or the feature we are part of 4. The nearest street (up to 3 miles) 5. Not linked It seems that it takes one of the streets from the associatedStreet relation to work with. The segment should be long enough (longer than 50-100 m ?). It then works with this street. It simply ignores the tags on the associatedStreet. This would make the relation useless to solve any issue regarding name and postcode for streets that are the border between 2 villages. The 2 names in the standard tag are required, otherwise many QA-tools will complain name:left/right is not recognized, or are they ? (yeah I know do not tag for ... :-) ) You can't use a semi-colon in the name (to indicate multiple names) otherwise another bunch of QA-tools complain that there are 2 names on a highway. BTW, the postcode is also wrong in my example. It should be 2840. It has time, Glenn, it's wrong for several weeks now, so a day more or less does not matter. m On Thu, Nov 14, 2013 at 10:26 AM, Ben Abelshausen ben.abelshau...@gmail.com wrote: On Thu, Nov 14, 2013 at 10:20 AM, Glenn Plas gl...@byte-consult.bewrote: If it can wait I'll check this evening with full attention. That's up to marc. But I guess he would like to see his work be made into something useful. :-) Met vriendelijke groeten, Best regards, Ben Abelshausen ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] POI Address problem
I agree with that, address:street is easily to change or view at all apps for smartphones or tablets too. 2013/11/15 Marc Gemis marc.ge...@gmail.com Got this answer from lonvia on help.osm.org You've mapped it correctly, Nominatim is just not very good at updating associatedStreet relations. It's a known bughttps://trac.openstreetmap.org/ticket/4619 . Here is what happened: you've originally put the house into this associatedStreet relationhttp://www.openstreetmap.org/browse/relation/2594673 which does contain the 'Pierstraat - Matenstraat' street. Nominatim simply uses the first street it finds in such a relation for the name an ignores all tags on the relation itself, so that is where the name comes from. Later you have moved the house to the new relation and that move was not caught by Nominatim's update process. The houses will only be updated when they are changed themselves again. also interesting is this quote from lonvia in the above mentioned bug: Nominatim would be perfectly happy if you added only addr:street tags and got rid of the associatedStreet relations. The relations mostly don't carry any additional information and are a bit of a pain to handle. addr:street is much better supported. So I wonder more and more whether we should add those theoretically nice associatedStreet relations On Thu, Nov 14, 2013 at 1:10 PM, Marc Gemis marc.ge...@gmail.com wrote: the help thread is here: https://help.openstreetmap.org/questions/28075/how-to-correctly-map-a-pois-address seems that Nominatim was not updated after the associatedStreet-relation update On Thu, Nov 14, 2013 at 10:50 AM, Marc Gemis marc.ge...@gmail.comwrote: I'm reading http://wiki.openstreetmap.org/wiki/Nominatim/Development_overviewagain, especially the section on Building indexing Buildings, houses and other lower than street level features (i.e., bus stops, phone boxes, etc.) are indexed by relating them to their most appropriate nearby street. The street is calculated as: 1. The street member of an associatedStreet relation 2. If the node is part of a way: 2.1 If this way is street level, than that street 2.2 The street member of an associatedStreet relation that this way is in 2.3 A street way with 50/100 meters and parallel with the way we are in 3. A nearby street with the name given in addr:street of the feature we are in or the feature we are part of 4. The nearest street (up to 3 miles) 5. Not linked It seems that it takes one of the streets from the associatedStreet relation to work with. The segment should be long enough (longer than 50-100 m ?). It then works with this street. It simply ignores the tags on the associatedStreet. This would make the relation useless to solve any issue regarding name and postcode for streets that are the border between 2 villages. The 2 names in the standard tag are required, otherwise many QA-tools will complain name:left/right is not recognized, or are they ? (yeah I know do not tag for ... :-) ) You can't use a semi-colon in the name (to indicate multiple names) otherwise another bunch of QA-tools complain that there are 2 names on a highway. BTW, the postcode is also wrong in my example. It should be 2840. It has time, Glenn, it's wrong for several weeks now, so a day more or less does not matter. m On Thu, Nov 14, 2013 at 10:26 AM, Ben Abelshausen ben.abelshau...@gmail.com wrote: On Thu, Nov 14, 2013 at 10:20 AM, Glenn Plas gl...@byte-consult.bewrote: If it can wait I'll check this evening with full attention. That's up to marc. But I guess he would like to see his work be made into something useful. :-) Met vriendelijke groeten, Best regards, Ben Abelshausen ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be -- Ivo De Broeck Valleilaan 13 3360 Korbeek-lo tel +32 16 43 84 93 gsm +32 486 17 61 13 spanje tel +34 966 841 726 gsm +34 603 661 778 ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] POI Address problem
Here are a few applications which suffer from repeating the same information millions of times: PostGIS wget the bandwith of my internet provider for downloading all that cruft scripts to unpack and read those exorbitantly long XML files, even when I'm not working with those addresses, so I'm unpacking and processing them in vain over and over again. Even with 8G of memory I can't seem to hand JOSM more than about 1G to work with. Every time autosave kicks in, I'm waiting. I'll be waiting even longer when those xml files grow even larger. And technology improvements like SSDs only help so much. Applications on mobile platforms (the ones Ivo is talking about) would also benefit from a sensible approach. All that processing drains the battery even faster and memory for those devices are at premium prices. So it would make a lot more sense for those apps to be improved, than for us to start millioniplicating data. Jo 2013/11/15 Ivo De Broeck ivo.debro...@gmail.com I agree with that, address:street is easily to change or view at all apps for smartphones or tablets too. 2013/11/15 Marc Gemis marc.ge...@gmail.com Got this answer from lonvia on help.osm.org You've mapped it correctly, Nominatim is just not very good at updating associatedStreet relations. It's a known bughttps://trac.openstreetmap.org/ticket/4619 . Here is what happened: you've originally put the house into this associatedStreet relationhttp://www.openstreetmap.org/browse/relation/2594673 which does contain the 'Pierstraat - Matenstraat' street. Nominatim simply uses the first street it finds in such a relation for the name an ignores all tags on the relation itself, so that is where the name comes from. Later you have moved the house to the new relation and that move was not caught by Nominatim's update process. The houses will only be updated when they are changed themselves again. also interesting is this quote from lonvia in the above mentioned bug: Nominatim would be perfectly happy if you added only addr:street tags and got rid of the associatedStreet relations. The relations mostly don't carry any additional information and are a bit of a pain to handle. addr:street is much better supported. So I wonder more and more whether we should add those theoretically nice associatedStreet relations On Thu, Nov 14, 2013 at 1:10 PM, Marc Gemis marc.ge...@gmail.com wrote: the help thread is here: https://help.openstreetmap.org/questions/28075/how-to-correctly-map-a-pois-address seems that Nominatim was not updated after the associatedStreet-relation update On Thu, Nov 14, 2013 at 10:50 AM, Marc Gemis marc.ge...@gmail.comwrote: I'm reading http://wiki.openstreetmap.org/wiki/Nominatim/Development_overviewagain, especially the section on Building indexing Buildings, houses and other lower than street level features (i.e., bus stops, phone boxes, etc.) are indexed by relating them to their most appropriate nearby street. The street is calculated as: 1. The street member of an associatedStreet relation 2. If the node is part of a way: 2.1 If this way is street level, than that street 2.2 The street member of an associatedStreet relation that this way is in 2.3 A street way with 50/100 meters and parallel with the way we are in 3. A nearby street with the name given in addr:street of the feature we are in or the feature we are part of 4. The nearest street (up to 3 miles) 5. Not linked It seems that it takes one of the streets from the associatedStreet relation to work with. The segment should be long enough (longer than 50-100 m ?). It then works with this street. It simply ignores the tags on the associatedStreet. This would make the relation useless to solve any issue regarding name and postcode for streets that are the border between 2 villages. The 2 names in the standard tag are required, otherwise many QA-tools will complain name:left/right is not recognized, or are they ? (yeah I know do not tag for ... :-) ) You can't use a semi-colon in the name (to indicate multiple names) otherwise another bunch of QA-tools complain that there are 2 names on a highway. BTW, the postcode is also wrong in my example. It should be 2840. It has time, Glenn, it's wrong for several weeks now, so a day more or less does not matter. m On Thu, Nov 14, 2013 at 10:26 AM, Ben Abelshausen ben.abelshau...@gmail.com wrote: On Thu, Nov 14, 2013 at 10:20 AM, Glenn Plas gl...@byte-consult.bewrote: If it can wait I'll check this evening with full attention. That's up to marc. But I guess he would like to see his work be made into something useful. :-) Met vriendelijke groeten, Best regards, Ben Abelshausen ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list
Re: [OSM-talk-be] POI Address problem
I didn't say that we have to repeat the addr:postcode, or addr:province, etc. That's not taken from the node/building anyway. There we really need an area representing the postcode. So repeating the address field or keeping a reference to another table does make a huge difference, a varchar(1024) or a pointer of 64 bits ? Where the latter saves you a join to find the streetname. You'll need the streetname field anyway, since not everybody is using associatedStreets. And don't forget our Belgian compromise to place the name on the street, the relation and the node/building. Did you see http://www.openstreetmap.org/user/Pieren/diary/20385 ? More or less the same conclusions., associatedStreets aren't accepted. The associatedStreet relation is the best solution from a database design point, but with the current mappers (non-dba's) and the set of tools we have (both editors and consumers), it seems more like a useless vehicle that's difficult to explain and maintain. And BTW, I can say the same for repeating the name of the city on each busstop, a waste of diskspace :-) Maybe we should more focus on getting the city and postal code boundaries into OSM, so we do not have to repeat that data on the lower level features (not on the relations, nor on the nodes). When the data can be found by the position of a node, there is no need to repeat it. When we can start the import of AGiV/Crab it might be easy to have the relations and the necessary information on the nodes, but right now, with the current set of tools of JOSM, it's hard to keep it correct. I don't know for other editors. Furthermore in JOSM you can't add POI's and buildings with the same house number without warnings. This might scare people as well. A lot people that add information for the first time, add an address in iD, without associatedStreet. So during the import, a poor soul might figure out how to merge that data with the imported data and update the associatedStreet in the correct way. I'm thinking how I can describe this so less experienced mappers than you and me understand what they should do. Anyway, off my soapbox. For you poor machine, which options to you give to JOSM at startup time? Do you use -Xmx (max heap size) ? Do you use a 64-bit java VM ? m On Fri, Nov 15, 2013 at 12:38 PM, Jo winfi...@gmail.com wrote: Here are a few applications which suffer from repeating the same information millions of times: PostGIS wget the bandwith of my internet provider for downloading all that cruft scripts to unpack and read those exorbitantly long XML files, even when I'm not working with those addresses, so I'm unpacking and processing them in vain over and over again. Even with 8G of memory I can't seem to hand JOSM more than about 1G to work with. Every time autosave kicks in, I'm waiting. I'll be waiting even longer when those xml files grow even larger. And technology improvements like SSDs only help so much. Applications on mobile platforms (the ones Ivo is talking about) would also benefit from a sensible approach. All that processing drains the battery even faster and memory for those devices are at premium prices. So it would make a lot more sense for those apps to be improved, than for us to start millioniplicating data. Jo 2013/11/15 Ivo De Broeck ivo.debro...@gmail.com I agree with that, address:street is easily to change or view at all apps for smartphones or tablets too. 2013/11/15 Marc Gemis marc.ge...@gmail.com Got this answer from lonvia on help.osm.org You've mapped it correctly, Nominatim is just not very good at updating associatedStreet relations. It's a known bughttps://trac.openstreetmap.org/ticket/4619 . Here is what happened: you've originally put the house into this associatedStreet relationhttp://www.openstreetmap.org/browse/relation/2594673 which does contain the 'Pierstraat - Matenstraat' street. Nominatim simply uses the first street it finds in such a relation for the name an ignores all tags on the relation itself, so that is where the name comes from. Later you have moved the house to the new relation and that move was not caught by Nominatim's update process. The houses will only be updated when they are changed themselves again. also interesting is this quote from lonvia in the above mentioned bug: Nominatim would be perfectly happy if you added only addr:street tags and got rid of the associatedStreet relations. The relations mostly don't carry any additional information and are a bit of a pain to handle. addr:street is much better supported. So I wonder more and more whether we should add those theoretically nice associatedStreet relations On Thu, Nov 14, 2013 at 1:10 PM, Marc Gemis marc.ge...@gmail.comwrote: the help thread is here: https://help.openstreetmap.org/questions/28075/how-to-correctly-map-a-pois-address seems that Nominatim was not updated after the associatedStreet-relation update On Thu, Nov 14, 2013
Re: [OSM-talk-be] POI Address problem
Thanks Ben. I've also posted it on help.openstreetmap.org, hoping that some Nominatim expert/developer will pick it up and explain what's going on. And indeed the complexity of the street has nothing to do with it. It could happen anywhere else I assume. regards m On Thu, Nov 14, 2013 at 9:26 AM, Ben Abelshausen ben.abelshau...@gmail.comwrote: Hey Marc, I can't see anything wrong with what you did here. It a complex street but that part should be pretty straightforward. It all very clean and in the associatedStreet, nice and close to the road with an housnumber tag :-) I don't have the time at the moment but maybe someone could look into nominatim in detail and figure out how it works but I think what you have done is correct and should not be changed. Ma Met vriendelijke groeten, Best regards, Ben Abelshausen On Wed, Nov 13, 2013 at 12:18 PM, Marc Gemis marc.ge...@gmail.com wrote: Can someone please tell me how I can properly tag this POI http://www.openstreetmap.org/browse/way/237662466 ? It's a shop located in the Pierstraat in Reet. The building has an addr:street tag and is part of an associatedStreet relation. However Nominatim (and openlinkmap) places it in the Pierstraat - Matenstraat. Do a look-up for Vero Golf on osm.org I know this is a complex street that starts as Pierstraat in Reet/Rumst in the east, becomes Pierstraat (Reet side)- Reetsesteenweg (Aartselaar side), Pierstraat (both Reet Aartselaar), Pierstraat (Aartselaar side) - Matenstraat (Niel side) while traveling to the west. Nevertheless the building is nearer a Pierstraat-Pierstraat part and has all those additional tags. So what's the use of all this additional information when the reference implementation (=Nominatim) just ignores it? m ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] POI Address problem
OK and if this does not help, we will need to investigate further. I used to know one of the nominatim developers but i'm not sure if she is still working on this (lonvia). Met vriendelijke groeten, Best regards, Ben Abelshausen On Thu, Nov 14, 2013 at 9:31 AM, Marc Gemis marc.ge...@gmail.com wrote: Thanks Ben. I've also posted it on help.openstreetmap.org, hoping that some Nominatim expert/developer will pick it up and explain what's going on. And indeed the complexity of the street has nothing to do with it. It could happen anywhere else I assume. regards m On Thu, Nov 14, 2013 at 9:26 AM, Ben Abelshausen ben.abelshau...@gmail.com wrote: Hey Marc, I can't see anything wrong with what you did here. It a complex street but that part should be pretty straightforward. It all very clean and in the associatedStreet, nice and close to the road with an housnumber tag :-) I don't have the time at the moment but maybe someone could look into nominatim in detail and figure out how it works but I think what you have done is correct and should not be changed. Ma Met vriendelijke groeten, Best regards, Ben Abelshausen On Wed, Nov 13, 2013 at 12:18 PM, Marc Gemis marc.ge...@gmail.comwrote: Can someone please tell me how I can properly tag this POI http://www.openstreetmap.org/browse/way/237662466 ? It's a shop located in the Pierstraat in Reet. The building has an addr:street tag and is part of an associatedStreet relation. However Nominatim (and openlinkmap) places it in the Pierstraat - Matenstraat. Do a look-up for Vero Golf on osm.org I know this is a complex street that starts as Pierstraat in Reet/Rumst in the east, becomes Pierstraat (Reet side)- Reetsesteenweg (Aartselaar side), Pierstraat (both Reet Aartselaar), Pierstraat (Aartselaar side) - Matenstraat (Niel side) while traveling to the west. Nevertheless the building is nearer a Pierstraat-Pierstraat part and has all those additional tags. So what's the use of all this additional information when the reference implementation (=Nominatim) just ignores it? m ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] POI Address problem
This is how it trickles down to that address: http://nominatim.openstreetmap.org/details.php?place_id=9140432282 The name comes from an incorrect name tag on this way: http://www.openstreetmap.org/browse/way/22949350 the 2nd way from the Nodes list is why this is getting matched. ( http://www.openstreetmap.org/browse/way/109899785 ) Glenn On 14-11-13 09:26, Ben Abelshausen wrote: Hey Marc, I can't see anything wrong with what you did here. It a complex street but that part should be pretty straightforward. It all very clean and in the associatedStreet, nice and close to the road with an housnumber tag :-) I don't have the time at the moment but maybe someone could look into nominatim in detail and figure out how it works but I think what you have done is correct and should not be changed. Ma Met vriendelijke groeten, Best regards, Ben Abelshausen On Wed, Nov 13, 2013 at 12:18 PM, Marc Gemis marc.ge...@gmail.com mailto:marc.ge...@gmail.com wrote: Can someone please tell me how I can properly tag this POI http://www.openstreetmap.org/browse/way/237662466 ? It's a shop located in the Pierstraat in Reet. The building has an addr:street tag and is part of an associatedStreet relation. However Nominatim (and openlinkmap) places it in the Pierstraat - Matenstraat. Do a look-up for Vero Golf on osm.org http://osm.org I know this is a complex street that starts as Pierstraat in Reet/Rumst in the east, becomes Pierstraat (Reet side)- Reetsesteenweg (Aartselaar side), Pierstraat (both Reet Aartselaar), Pierstraat (Aartselaar side) - Matenstraat (Niel side) while traveling to the west. Nevertheless the building is nearer a Pierstraat-Pierstraat part and has all those additional tags. So what's the use of all this additional information when the reference implementation (=Nominatim) just ignores it? m ___ Talk-be mailing list Talk-be@openstreetmap.org mailto:Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] POI Address problem
Glenn, I'm not really seeing it yet. Do you mean that the match is there because the segment with two names is also in the associatedStreet relation? http://www.openstreetmap.org/browse/relation/2594673 ... and according to what marc is saying these tags are correct? http://www.openstreetmap.org/browse/way/22949350 Met vriendelijke groeten, Best regards, Ben Abelshausen ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] POI Address problem
Hey Ben, I see the why and how, but I admit I don't see how to fix this yet and I have trouble explaining. It's using the general tag from http://www.openstreetmap.org/browse/way/22949350 So it's ignoring name:left , name:right. So that implementation is not picked up for sure. I think the problem is that pierstraat - piertraat isn't used as a source for the name, it's the closest way. Makes no sense to use the other one. But that's where the relations have their influence, so I bet it's located in the relation. Somehow I think that this node has everything to do with it : http://www.openstreetmap.org/browse/node/247269245 Don't have all the answers yet, but I will check this out deeper later today. I've got more issues with associatedStreet relations with nominatim for a while now. Everyday they hack up the nominatim code and it can all change in the next version, but I don't think anyone can explain to us now how it really works without having to go through all the logic it uses in delivering a address line for each possible country Glenn On 14-11-13 09:59, Ben Abelshausen wrote: Glenn, I'm not really seeing it yet. Do you mean that the match is there because the segment with two names is also in the associatedStreet relation? http://www.openstreetmap.org/browse/relation/2594673 ... and according to what marc is saying these tags are correct? http://www.openstreetmap.org/browse/way/22949350 Met vriendelijke groeten, Best regards, Ben Abelshausen ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] POI Address problem
Could a solution be to remove the segment with the duplicate name and consider streets with duplicates names as a seperate entity? Met vriendelijke groeten, Best regards, Ben Abelshausen ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] POI Address problem
I haven't looked in josm yet, but I think http://www.openstreetmap.org/browse/way/22949350 should not have 2 names in the standard name tag.It still doesn't explain why that tag is being used so far out of the way with ways in front of it to choose from. If it can wait I'll check this evening with full attention. Glenn On 14-11-13 10:14, Ben Abelshausen wrote: Could a solution be to remove the segment with the duplicate name and consider streets with duplicates names as a seperate entity? Met vriendelijke groeten, Best regards, Ben Abelshausen ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] POI Address problem
On Thu, Nov 14, 2013 at 10:20 AM, Glenn Plas gl...@byte-consult.be wrote: If it can wait I'll check this evening with full attention. That's up to marc. But I guess he would like to see his work be made into something useful. :-) Met vriendelijke groeten, Best regards, Ben Abelshausen ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] POI Address problem
I'm reading http://wiki.openstreetmap.org/wiki/Nominatim/Development_overview again, especially the section on Building indexing Buildings, houses and other lower than street level features (i.e., bus stops, phone boxes, etc.) are indexed by relating them to their most appropriate nearby street. The street is calculated as: 1. The street member of an associatedStreet relation 2. If the node is part of a way: 2.1 If this way is street level, than that street 2.2 The street member of an associatedStreet relation that this way is in 2.3 A street way with 50/100 meters and parallel with the way we are in 3. A nearby street with the name given in addr:street of the feature we are in or the feature we are part of 4. The nearest street (up to 3 miles) 5. Not linked It seems that it takes one of the streets from the associatedStreet relation to work with. The segment should be long enough (longer than 50-100 m ?). It then works with this street. It simply ignores the tags on the associatedStreet. This would make the relation useless to solve any issue regarding name and postcode for streets that are the border between 2 villages. The 2 names in the standard tag are required, otherwise many QA-tools will complain name:left/right is not recognized, or are they ? (yeah I know do not tag for ... :-) ) You can't use a semi-colon in the name (to indicate multiple names) otherwise another bunch of QA-tools complain that there are 2 names on a highway. BTW, the postcode is also wrong in my example. It should be 2840. It has time, Glenn, it's wrong for several weeks now, so a day more or less does not matter. m On Thu, Nov 14, 2013 at 10:26 AM, Ben Abelshausen ben.abelshau...@gmail.com wrote: On Thu, Nov 14, 2013 at 10:20 AM, Glenn Plas gl...@byte-consult.bewrote: If it can wait I'll check this evening with full attention. That's up to marc. But I guess he would like to see his work be made into something useful. :-) Met vriendelijke groeten, Best regards, Ben Abelshausen ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] POI Address problem
the help thread is here: https://help.openstreetmap.org/questions/28075/how-to-correctly-map-a-pois-address seems that Nominatim was not updated after the associatedStreet-relation update On Thu, Nov 14, 2013 at 10:50 AM, Marc Gemis marc.ge...@gmail.com wrote: I'm reading http://wiki.openstreetmap.org/wiki/Nominatim/Development_overview again, especially the section on Building indexing Buildings, houses and other lower than street level features (i.e., bus stops, phone boxes, etc.) are indexed by relating them to their most appropriate nearby street. The street is calculated as: 1. The street member of an associatedStreet relation 2. If the node is part of a way: 2.1 If this way is street level, than that street 2.2 The street member of an associatedStreet relation that this way is in 2.3 A street way with 50/100 meters and parallel with the way we are in 3. A nearby street with the name given in addr:street of the feature we are in or the feature we are part of 4. The nearest street (up to 3 miles) 5. Not linked It seems that it takes one of the streets from the associatedStreet relation to work with. The segment should be long enough (longer than 50-100 m ?). It then works with this street. It simply ignores the tags on the associatedStreet. This would make the relation useless to solve any issue regarding name and postcode for streets that are the border between 2 villages. The 2 names in the standard tag are required, otherwise many QA-tools will complain name:left/right is not recognized, or are they ? (yeah I know do not tag for ... :-) ) You can't use a semi-colon in the name (to indicate multiple names) otherwise another bunch of QA-tools complain that there are 2 names on a highway. BTW, the postcode is also wrong in my example. It should be 2840. It has time, Glenn, it's wrong for several weeks now, so a day more or less does not matter. m On Thu, Nov 14, 2013 at 10:26 AM, Ben Abelshausen ben.abelshau...@gmail.com wrote: On Thu, Nov 14, 2013 at 10:20 AM, Glenn Plas gl...@byte-consult.bewrote: If it can wait I'll check this evening with full attention. That's up to marc. But I guess he would like to see his work be made into something useful. :-) Met vriendelijke groeten, Best regards, Ben Abelshausen ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
[OSM-talk-be] POI Address problem
Can someone please tell me how I can properly tag this POI http://www.openstreetmap.org/browse/way/237662466 ? It's a shop located in the Pierstraat in Reet. The building has an addr:street tag and is part of an associatedStreet relation. However Nominatim (and openlinkmap) places it in the Pierstraat - Matenstraat. Do a look-up for Vero Golf on osm.org I know this is a complex street that starts as Pierstraat in Reet/Rumst in the east, becomes Pierstraat (Reet side)- Reetsesteenweg (Aartselaar side), Pierstraat (both Reet Aartselaar), Pierstraat (Aartselaar side) - Matenstraat (Niel side) while traveling to the west. Nevertheless the building is nearer a Pierstraat-Pierstraat part and has all those additional tags. So what's the use of all this additional information when the reference implementation (=Nominatim) just ignores it? m ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
