[OSM-talk-be] POI Address problem

Marc Gemis marc.gemis at gmail.com
Fri Nov 15 15:28:54 UTC 2013


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 <winfixit at 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.debroeck at 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.gemis at 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 bug<https://trac.openstreetmap.org/ticket/4619>
>>> .
>>>
>>> Here is what happened: you've originally put the house into this
>>> associatedStreet relation<http://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.gemis at 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.gemis at gmail.com>wrote:
>>>>
>>>>> 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.abelshausen at gmail.com> wrote:
>>>>>
>>>>>>
>>>>>> On Thu, Nov 14, 2013 at 10:20 AM, Glenn Plas <glenn at 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 at openstreetmap.org
>>>>>> https://lists.openstreetmap.org/listinfo/talk-be
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> Talk-be mailing list
>>> Talk-be at 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 at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>>
>
> _______________________________________________
> Talk-be mailing list
> Talk-be at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-be/attachments/20131115/f54b41d0/attachment.htm>


More information about the Talk-be mailing list