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
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
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
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
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
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
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
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)
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
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
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. (
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?
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
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
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
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
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 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
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
19 matches
Mail list logo
