Re: [OSM-talk-be] samenvoegen van stukken weg
On Wed, Jan 7, 2015 at 5:12 PM, André Pirard a.pirard.pa...@gmail.com wrote: And I made 5 happy ones, in order: the dog (unimaginable), my neighbour, myself, the doctor ... and you. :-) :-) :-) me happy ! m ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] samenvoegen van stukken weg
Turn restrictions not for Mr. Everybody ? Did you try the iD UI for that ? Simpler than that is almost possible (besides interpretation from spoken natural language). I've been thinking a bit about your proposal during my walk this afternoon. I don't see how it helps when you have to turn a single way into a dual carriageway or vice versa. Another problem that I see is that those segments have to stay coupled to a street. Which makes it harder on the server to verify. As far as I see it now, the implementation of the OSM API for edits on the server is pretty straightforward and can handle large loads. The more things that have to be verified, the higher the load for a simple edit. But with your new explanation, it seems that you make it even more complex, since you create a segment / patch for each new combination of tags. So when one wants to add an attribute to a street, one does not have to split the street but X number of segments that might already exist ? With as only benefit that there is only 1 object that represents a street. Which is right now a number of OSM-ways that accidentally have the same name ? I think the current approach of splitting a street is much easier then. We just need an API to retrieve all OSM-ways that form a street. Some might say associatedStreet, others say Street (cfr. discussion on cycleways), or maybe some upcoming Overpass feature might solve it (cfr a request from the maker of [1]) AFAIK there are no restrictions implied by a service road. Some navigation systems put a penalty on service roads, as they are typically not for through traffic. regards m [1] http://osm.mueschelsoft.de/cgi-bin/render.pl -- shows all lane direction information for a street On Sat, Jan 3, 2015 at 1:47 PM, André Pirard a.pirard.pa...@gmail.com wrote: On 2015-01-03 08:27, Marc Gemis wrote : I once read your proposal on the wiki. The main drawback that I see is that one will get an awful lot of layers (or whatever you want to call them). For each property you add to a street a need to create a new layer. After verifying of course that there isn't already a layer with that property. In that case you have to split the layer at the right place. No. There is not a layer for each property but for each segment of the road that has a different sets of properties. Take a bridge as an example. With the present scheme, the road is split in three parts. With my scheme, it has only two parts: the road and the patch for the bridge. And the patch for the bridge very clearly contains all the tags that relate to the bridge only, for example a special speed limit and a name. Presently, if two paths arriving at a main road are 50 m apart like this and a walk uses the paths | *---*- | then the road must be split as shown and the red part becomes part of the walk. With patches, the road remains intact and the patch is in the walk that is self contained. I try to imaging how a UI to edit that would look like. Or software that uses that data. I wonder whether it would much easier to work with such a structure. hard to tell. You are probably to much ahead of your time with this proposal. The UI would make very clear what the bridge is and the user would have a very clear view of what its particular tags are instead of being mixed with the tags of the road. For the walk, the user dealing with the main street would have very little concern with it. The users would not have to compare the tags of different splits and wonder to what they relate. It's pure simplicity. I have now devised a much more simpler way to do patches than what I explained before. But, as you almost say, I would lose my time explaining that. Unfortunately, this means that OSM will remain very complicated, mapping restricted to gurus and subject to many mistakes. For example, tagging a simple turn restriction is NOT for Mr Everybody and when I make a simple GPS trip nearby, it goes through a track through the meadows instead of the main road. That's probably because the definition of a service road is fuzzy and does not say if it's an access restrictions or not. The mapper and GPS writer probably had different points of view about that. And that happens in several places. Cheers André. regards m PS, it is indeed pretty confusing that something with one 'l' in one language has two in the other, and has another meaning in the second language with one l. On Sat, Jan 3, 2015 at 2:34 AM, André Pirard a.pirard.pa...@gmail.com wrote: On 2015-01-02 19:01, Marc Gemis wrote : 2015-01-02 17:11 GMT+01:00 André Pirard a.pirard.pa...@gmail.com: J'ai un jour écrit un article décrivant une méthode pour ne plus devoir découper les chemins mais ça n'a intéressé personne. I've read somewhere that navigation software will split all ways at a crossing in order to be able to calculate all possible routes. So the merging
Re: [OSM-talk-be] samenvoegen van stukken weg
On 2015-01-03 17:39, Marc Gemis wrote : I've been thinking a bit about your proposal during my walk this afternoon. I don't see how it helps when you have to turn a single way into a dual carriageway or vice versa. Another problem that I see is that those segments have to stay coupled to a street. Which makes it harder on the server to verify. As far as I see it now, the implementation of the OSM API for edits on the server is pretty straightforward and can handle large loads. The more things that have to be verified, the higher the load for a simple edit. ? But with your new explanation, it seems that you make it even more complex, since you create a segment / patch for each new combination of tags. So when one wants to add an attribute to a street, one does not have to split the street but X number of segments that might already exist ? It seems that you did not understand. No patch is created for each new combination of tags. They are created only over the segment of the road that has tags different from the rest and they contain only the tags that are different. Creating a new patch does not splits existing patches, they overlap like they overlap the main road. Example: cobble stones patch --- road -- 50 km/h patch 50 km/h has been added without splitting anything and a part of the road is both cobble stones and 50 km/h, a new combination that does not split anything. Both patches are separate, well isolated concepts that do not interfere with each other and that can be changed or removed without (almost) any concern for the rest without changing anything else. Now, I'm sorry that I have to close this discussion because I'm losing my time. With as only benefit that there is only 1 object that represents a street. Which is right now a number of OSM-ways that accidentally have the same name ? I think the current approach of splitting a street is much easier then. We just need an API to retrieve all OSM-ways that form a street. Some might say "associatedStreet", others say "Street" (cfr. discussion on cycleways), or maybe some upcoming Overpass feature might solve it (cfr a request from the maker of [1]) AFAIK there are no restrictions implied by a service road. Some navigation systems put a penalty on service roads, as they are typically not for through traffic. regards m [1] http://osm.mueschelsoft.de/cgi-bin/render.pl -- shows all lane direction information for a street On Sat, Jan 3, 2015 at 1:47 PM, André Pirard a.pirard.pa...@gmail.com wrote: On 2015-01-03 08:27, Marc Gemis wrote : I once read your proposal on the wiki. The main drawback that I see is that one will get an awful lot of "layers" (or whatever you want to call them). For each property you add to a street a need to create a new layer. After verifying of course that there isn't already a layer with that property. In that case you have to split the layer at the right place. No. There is not a "layer" for each property but for each segment of the road that has a different sets of properties. Take a bridge as an example. With the present scheme, the road is split in three parts. With my scheme, it has only two parts: the road and the patch for the bridge. And the patch for the bridge very clearly contains all the tags that relate to the bridge only, for example a special speed limit and a name. Presently, if two paths arriving at a main road are 50 m apart like this and a walk uses the paths | | then the road must be split as shown and the red part becomes part of the walk. With patches, the road remains intact and the patch is in
Re: [OSM-talk-be] samenvoegen van stukken weg
Splitsen is meestal gedaan omdat er net een verschil is (verschillende maximum snelheid, maximum gewicht, deel van een route relatie, ...). JOSM klaagt niet als de tags geen conflict vertonen (vb. een maximum gewicht op een deel van de weg, maar niet op de rest), dus zelfs in JOSM kan het samenvoegen gevaarlijk zijn. Het splitsen van een weg is daarentegen heel wat minder gevaarlijk. Groeten, Sander Op 2 januari 2015 13:05 schreef Glenn Plas gl...@byte-consult.be: Ik kom vaak wegen tegen die getekend zijn in iD en die zijn meestal niet connected met de andere ways.Visueel lijkt het wel ok maar logisch gezien staan de uiteinde van de nodes op de way, niet joined met de way. JOSM zorgt voor de relaties automatisch, samenvoegen zou daar niet zoveel schade aanrichten dan in iD. Glenn Dit was een paar maanden geleden ook aan de gang in Almere (Nederland). Ik snap de beweegredenen ook niet. Een perfecte weg verwijderen om een nieuwe te tekenen? Waarom dan niet direkt samenvoegen, dat is toch veel minder werk? Of is dat lastig in iD? Maarten ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be -- Everything is going to be 200 OK. ___ 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] samenvoegen van stukken weg
On 2015-01-02 12:14, Marc Gemis wrote: Ik zou er langs deze weg iedereen willen op wijzen dat het gevaarlijk is om stukken weg samen te voegen tot 1 geheel. Zeker als dit gebeurt door de oude weg weg te smijten en een nieuwe te tekenen. Het heeft ook geen enkel nut. In de meeste gevallen zijn de wegen gesplitst voor een goede reden: andere eigenschappen, deel van een relatie. iD laat dit niet allemaal zien. Ik heb de auteur van deze changeset [1] gevraagd om het boeltje te herstellen, maar hij heeft er nog wel een paar gelijkaardige wijzigingen gedaan in de buurt van Lier. Misschien zijn er daar fietsroutes gebroken. In [1] weet ik zeker dat de wandelroutes verwijderd zijn. Dit was een paar maanden geleden ook aan de gang in Almere (Nederland). Ik snap de beweegredenen ook niet. Een perfecte weg verwijderen om een nieuwe te tekenen? Waarom dan niet direkt samenvoegen, dat is toch veel minder werk? Of is dat lastig in iD? Maarten ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
[OSM-talk-be] samenvoegen van stukken weg
Ik zou er langs deze weg iedereen willen op wijzen dat het gevaarlijk is om stukken weg samen te voegen tot 1 geheel. Zeker als dit gebeurt door de oude weg weg te smijten en een nieuwe te tekenen. Het heeft ook geen enkel nut. In de meeste gevallen zijn de wegen gesplitst voor een goede reden: andere eigenschappen, deel van een relatie. iD laat dit niet allemaal zien. Ik heb de auteur van deze changeset [1] gevraagd om het boeltje te herstellen, maar hij heeft er nog wel een paar gelijkaardige wijzigingen gedaan in de buurt van Lier. Misschien zijn er daar fietsroutes gebroken. In [1] weet ik zeker dat de wandelroutes verwijderd zijn. Hij zal misschien wel hulp nodig hebben om zijn wijzigingen terug te draaien. mvg m [1] https://www.openstreetmap.org/changeset/27816760 ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] samenvoegen van stukken weg
Hoi Sander, Hebben we over hetzelfde hier ? JOSM gaat u wel een dialoog geven hoor dat de tags verschillen. De user krijgt de merge window open. Het is aan de user om daarin te beslissen. Ik weet niet of je dat onder 'klagen' kan categoriseren, maar een kleine test hier geeft toch aan dat hij wel waarschuwt. (C - combine ways gedaan). Zie screenshot. http://aptum.bitless.be/screenie.png Glenn On 02-01-15 13:31, Sander Deryckere wrote: Splitsen is meestal gedaan omdat er net een verschil is (verschillende maximum snelheid, maximum gewicht, deel van een route relatie, ...). JOSM klaagt niet als de tags geen conflict vertonen (vb. een maximum gewicht op een deel van de weg, maar niet op de rest), dus zelfs in JOSM kan het samenvoegen gevaarlijk zijn. Het splitsen van een weg is daarentegen heel wat minder gevaarlijk. Groeten, Sander ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] samenvoegen van stukken weg
Ik kom vaak wegen tegen die getekend zijn in iD en die zijn meestal niet connected met de andere ways.Visueel lijkt het wel ok maar logisch gezien staan de uiteinde van de nodes op de way, niet joined met de way. JOSM zorgt voor de relaties automatisch, samenvoegen zou daar niet zoveel schade aanrichten dan in iD. Glenn Dit was een paar maanden geleden ook aan de gang in Almere (Nederland). Ik snap de beweegredenen ook niet. Een perfecte weg verwijderen om een nieuwe te tekenen? Waarom dan niet direkt samenvoegen, dat is toch veel minder werk? Of is dat lastig in iD? Maarten ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be -- Everything is going to be 200 OK. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] samenvoegen van stukken weg
On 2015-01-02 12:14, Marc Gemis wrote : Ik zou er langs deze weg iedereen willen op wijzen dat het gevaarlijk is om stukken weg samen te voegen tot 1 geheel. Zeker als dit gebeurt door de oude weg weg te smijten en een nieuwe te tekenen. Het heeft ook geen enkel nut. In de meeste gevallen zijn de wegen gesplitst voor een goede reden: andere eigenschappen, deel van een relatie. iD laat dit niet allemaal zien. Ik heb de auteur van deze changeset [1] gevraagd om het boeltje te herstellen, maar hij heeft er nog wel een paar gelijkaardige wijzigingen gedaan in de buurt van Lier. Misschien zijn er daar fietsroutes gebroken. In [1] weet ik zeker dat de wandelroutes verwijderd zijn. Hij zal misschien wel hulp nodig hebben om zijn wijzigingen terug te draaien. Je voudrais saisir cette occasion pour rappeler à tous qu'il est dangereux d'ajouter des morceaux loin ensemble en un tout. Surtout si ce est de jeter la vieille manière et dessiner un nouveau. Il dispose également d'aucune utilité. Dans la plupart des cas, les routes sont divisées pour une bonne raison: d'autres propriétés, qui fait partie d'une relation. iD montre ce pas tout. Je suis l'auteur de ce changeset [1] a demandé de récupérer les biens, mais il fait encore des changements similaires dans un proche Lier. Peut-être il ya des pistes cyclables brisées. Dans [1] Je suis sûr que les sentiers sont supprimés. Il sera probablement besoin d'aide pour inverser ses amendements. Utilisez JOSM. Il détecte la majorité des problèmes de fusion. Il va même jusqu'à avertir que faire une opération sans charger des données supplémentaires est susceptible de provoquer un problème avec des données invisibles et inconnues. J'ai vu beaucoup de chemins inutilement découpés. C'est parfaitement hilarant de voir Nominatim donner 10 résultats pour la même rue. J'ai un jour écrit un article décrivant une méthode pour ne plus devoir découper les chemins mais ça n'a intéressé personne. André. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] samenvoegen van stukken weg
't gaat in dit geval wel om een delete + opnieuw tekenen. JOSM zal dan wel klagen dan je een weg uit een relatie haalt. Ik weet niet wat iD in zo'n geval doet. m 2015-01-02 13:31 GMT+01:00 Sander Deryckere sander...@gmail.com: Splitsen is meestal gedaan omdat er net een verschil is (verschillende maximum snelheid, maximum gewicht, deel van een route relatie, ...). JOSM klaagt niet als de tags geen conflict vertonen (vb. een maximum gewicht op een deel van de weg, maar niet op de rest), dus zelfs in JOSM kan het samenvoegen gevaarlijk zijn. Het splitsen van een weg is daarentegen heel wat minder gevaarlijk. Groeten, Sander Op 2 januari 2015 13:05 schreef Glenn Plas gl...@byte-consult.be: Ik kom vaak wegen tegen die getekend zijn in iD en die zijn meestal niet connected met de andere ways.Visueel lijkt het wel ok maar logisch gezien staan de uiteinde van de nodes op de way, niet joined met de way. JOSM zorgt voor de relaties automatisch, samenvoegen zou daar niet zoveel schade aanrichten dan in iD. Glenn Dit was een paar maanden geleden ook aan de gang in Almere (Nederland). Ik snap de beweegredenen ook niet. Een perfecte weg verwijderen om een nieuwe te tekenen? Waarom dan niet direkt samenvoegen, dat is toch veel minder werk? Of is dat lastig in iD? Maarten ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be -- Everything is going to be 200 OK. ___ 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] samenvoegen van stukken weg
is dat verschil niet te verklaren door de eerste checkbox (alleen conflicterende tags) vs. de tweede (tags met meerdere waarden) ? Ik weet niet wat de default is. Ik geloof wel dat JOSM je laatste keuze onthoudt. m. 2015-01-02 13:54 GMT+01:00 Glenn Plas gl...@byte-consult.be: Hoi Sander, Hebben we over hetzelfde hier ? JOSM gaat u wel een dialoog geven hoor dat de tags verschillen. De user krijgt de merge window open. Het is aan de user om daarin te beslissen. Ik weet niet of je dat onder 'klagen' kan categoriseren, maar een kleine test hier geeft toch aan dat hij wel waarschuwt. (C - combine ways gedaan). Zie screenshot. http://aptum.bitless.be/screenie.png Glenn On 02-01-15 13:31, Sander Deryckere wrote: Splitsen is meestal gedaan omdat er net een verschil is (verschillende maximum snelheid, maximum gewicht, deel van een route relatie, ...). JOSM klaagt niet als de tags geen conflict vertonen (vb. een maximum gewicht op een deel van de weg, maar niet op de rest), dus zelfs in JOSM kan het samenvoegen gevaarlijk zijn. Het splitsen van een weg is daarentegen heel wat minder gevaarlijk. Groeten, Sander ___ 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] samenvoegen van stukken weg
2015-01-02 17:11 GMT+01:00 André Pirard a.pirard.pa...@gmail.com: J'ai un jour écrit un article décrivant une méthode pour ne plus devoir découper les chemins mais ça n'a intéressé personne. I've read somewhere that navigation software will split all ways at a crossing in order to be able to calculate all possible routes. So the merging is only needed for rendering (in order not to show the name over and over again). Nominatim only shows the same way when the classification is different, see [1] for a split street showing multiple results, and [2] for one showing only one segment regards m. [1] http://nominatim.openstreetmap.org/search.php?q=steenweg+op+waarloosviewbox=-112.33%2C46.38%2C112.33%2C-46.38 [2] http://nominatim.openstreetmap.org/search.php?q=Molenstraat%2C+rumstviewbox=4.38%2C51.11%2C4.41%2C51.09 ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] samenvoegen van stukken weg
Yup, kan dit bevestigen, er moet minstens 1 tag verschillen op beide ways voor die dialog bovenkomt. Als ze beide een tag missen van elkaar krijg je de dialoog wel. Een way zonder tags combineren met eentje met krijg je absoluut geen waarschuwing, hij combineert gewoon silently. Glenn On 02-01-15 14:23, Maarten Deen wrote: On 2015-01-02 13:54, Glenn Plas wrote: Hoi Sander, Hebben we over hetzelfde hier ? JOSM gaat u wel een dialoog geven hoor dat de tags verschillen. De user krijgt de merge window open. Het is aan de user om daarin te beslissen. Je krijgt die dialoog alleen als de tags verschillen. Als een stuk weg een bepaalde tag heeft en het andere stuk niet dan krijg je die dialoog niet. Dus: maxspeed=30 en maxspeed=50 samenvoegen: dialoog, maxspeed=30 en geen maxspeed tag samenvoegen: geen dialoog. Maarten ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be -- Everything is going to be 200 OK. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] samenvoegen van stukken weg
We zijn eigenlijk wel beetje naast de feiten aan het praten ivm deze case, als de user de vorige weg verwijdert en dan een nieuwe tekent gaat die natuurlijk geen waarschuwing krijgen over de tags, enkel over eventuele relaties die in het gedrang kunnen komen. Glenn On 02-01-15 13:54, Glenn Plas wrote: Hoi Sander, Hebben we over hetzelfde hier ? JOSM gaat u wel een dialoog geven hoor dat de tags verschillen. De user krijgt de merge window open. Het is aan de user om daarin te beslissen. Ik weet niet of je dat onder 'klagen' kan categoriseren, maar een kleine test hier geeft toch aan dat hij wel waarschuwt. (C - combine ways gedaan). Zie screenshot. http://aptum.bitless.be/screenie.png Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] samenvoegen van stukken weg
On 2015-01-02 13:54, Glenn Plas wrote: Hoi Sander, Hebben we over hetzelfde hier ? JOSM gaat u wel een dialoog geven hoor dat de tags verschillen. De user krijgt de merge window open. Het is aan de user om daarin te beslissen. Je krijgt die dialoog alleen als de tags verschillen. Als een stuk weg een bepaalde tag heeft en het andere stuk niet dan krijg je die dialoog niet. Dus: maxspeed=30 en maxspeed=50 samenvoegen: dialoog, maxspeed=30 en geen maxspeed tag samenvoegen: geen dialoog. Maarten ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] samenvoegen van stukken weg
I once read your proposal on the wiki. The main drawback that I see is that one will get an awful lot of layers (or whatever you want to call them). For each property you add to a street a need to create a new layer. After verifying of course that there isn't already a layer with that property. In that case you have to split the layer at the right place. I try to imaging how a UI to edit that would look like. Or software that uses that data. I wonder whether it would much easier to work with such a structure. hard to tell. You are probably to much ahead of your time with this proposal. regards m PS, it is indeed pretty confusing that something with one 'l' in one language has two in the other, and has another meaning in the second language with one l. On Sat, Jan 3, 2015 at 2:34 AM, André Pirard a.pirard.pa...@gmail.com wrote: On 2015-01-02 19:01, Marc Gemis wrote : 2015-01-02 17:11 GMT+01:00 André Pirard a.pirard.pa...@gmail.com: J'ai un jour écrit un article décrivant une méthode pour ne plus devoir découper les chemins mais ça n'a intéressé personne. I've read somewhere that navigation software will split all ways at a crossing in order to be able to calculate all possible routes. So the merging is only needed for rendering (in order not to show the name over and over again). Obviously. With my method, there is no merging necessary because there is no splitting. If a part of a way has different tags, a sort of patch dummy way is created that overlays that part of the way and that contains the tags that are different. Difficult to explain in 2 lines. --- real highway with common tags - dummy way (patch) with bridge=yes If the consumer wants that, it can split the real highway, merge the tags and get the current situation. But it doesn't have to. In a further step, with slight software changes, the patch could be the element of a relation and relations would stop splitting the ways everywhere. Also, a turning restriction and other things could be done with very simple patches instead of complicated relations. All in all very powerful and easy to use, but, alas, it needs software changes. Nothing complicated but in the essential parts. Nominatim only shows the same way when the classification is different, see [1] for a split street showing multiple results, and [2] for one showing only one segment If you click on (details http://nominatim.openstreetmap.org/details.php?place_id=152179547) of [2] you see that it's only a split of Molenstraat and if you click on Search for more results http://nominatim.openstreetmap.org/search?format=htmlexclude_place_ids=152179547,90789266,57800141,152183937,58188920,57651969,89772878,126246678,2642012399,50709423,118353426,2642012397,2642012398,58361979,98773793,57793661,50786385,80736363,123201401,100889764,15832600accept-language=en,fr;q=0.8,wa;q=0.6,ru;q=0.4,nl;q=0.2viewbox=4.38%2C51.11%2C4.41%2C51.09q=Molenstraat%2C+rumst you get another split and it's not very clear at all how that street is split http://www.openstreetmap.org/search?query=molenstraat%20rumst#map=16/51.1009/4.3920, it looks like Nominatim is only showing parts of the splits. It would obviously work better if there were no splits but patches. André. PS: Oops, I first thought that molen were moles and I wondered if they were under the street and drinking a cup of coffee http://www.openstreetmap.org/way/166577477 ;-)They are in fact mills like this water mill http://www.openstreetmap.org/node/259975902#map=19/50.52639/5.52305 that I just mapped and that's probably the best known in Belgium. regards m. [1] http://nominatim.openstreetmap.org/search.php?q=steenweg+op+waarloosviewbox=-112.33%2C46.38%2C112.33%2C-46.38 [2] http://nominatim.openstreetmap.org/search.php?q=Molenstraat%2C+rumstviewbox=4.38%2C51.11%2C4.41%2C51.09 ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
