[Imports] Belgium address import

Serge Wroclawski emacsen at gmail.com
Sun Nov 24 18:26:05 UTC 2013


On Sun, Nov 24, 2013 at 11:10 AM, Randal Hale
<rjhale at northrivergeographic.com> wrote:
> What's the benefit of tying the address to the structure? I've seen this
> spoken about quite a bit.

There are a number of reasons:

1. What OSM objects represent

In OSM, we generally talk about ground observable truth and our
attributes are tied to physical objects. We talk about its address as
a property of the building. Anywhere you go in a building with on
address has that address. If the building has more than one street
address, you can mark the entrances.

This is the biggest reason.

2. Most (nearly all) of the time, those proposing nodes as standalone
are doing so because they have an external dataset they want to work
with OSM data

I've seen this argument made many times, but in all but one of the
dozen or so times it's come up, it's been by someone wanting to do an
import of an external dataset.

But that's a silly reason to change the internal representation of a
project, especially in light of #3

3. Almost always, the points are either wrong or meaningless

There are usually three ways that addresses come in from an external
dataset. Either they're points on the building centroid, or they're
points on the address entrance, or they're land parcel address

Let's take the building centroid first... An address on a building
centroid is just as meaningful (or meaningless) as the data in tags on
the building, except that in the case of having it on the building,
you know for sure that it's a property of the building.

Land parcels have much the same problem. What does it mean to have an
address in the middle of a land parcel, when what you really care
about is the structure on it? So that's silly too.

The last one is building entrances- and this one is more complicated.
If the data quality is super high, then you could make an argument
that we should tag the entrances as entrances and be done with it, but
the reality is that very often when you compare the data you get with
high quality imagery, you find that the entrances are "near" a
building, or they're on a place where there's no entrance. So then
you're back to the same detail you'd have with a building centroid
point, ie no added benefit.


Of course, if there was a dataset where the quality of the data was
super great, then I'd say tag the entrances as entrances- but even
then- unless the building has multiple entrances, why not tag the
building?

- Serge

>
> -----------------
> Randal Hale, GISP
> North River Geographic Systems, Inc
> http://www.northrivergeographic.com
> 423.653.3611 rjhale at northrivergeographic.com
> <mailto:rjhale at northrivergeographic.com>
> twitter:rjhale
> http://about.me/rjhale
>
>
> On 11/24/2013 08:32 AM, Kurt Roeckx wrote:
>>
>> On Sun, Nov 24, 2013 at 07:53:30AM -0500, Serge Wroclawski wrote:
>>>
>>> After thinking about this import- I think that it's overall a bad idea
>>> because the addresses are not tied to physical structures.
>>>
>>> It would be better, IMHO, until the areas have building coverage, to
>>> use this as an external resource.
>>
>> Note that the plan is to add the buildings before adding the
>> address information.  We are not interrested in address
>> information without the buildings.
>>
>> In the CRAB database they also try to link it to the building.
>> They just had a big project completed (GRB) that is a reference
>> map with has things like streets and buildings on it.  In the CRAB
>> database they try to link the address information to the building
>> from GRB.  But they also link it to the parcel from GRB and the
>> cadastre.  We get a coordinate of the centre of the building and
>> parcel.
>>
>> Note that the GRB is not something we can import currently.
>>
>> I really don't get why you think this is a bad idea.
>>
>>> Nonetheless I will reply to this address expansion because I have some
>>> experience with address expansion.
>>>
>>> On Sun, Nov 24, 2013 at 7:33 AM, Kurt Roeckx <kurt at roeckx.be> wrote:
>>>>
>>>> On Sun, Nov 24, 2013 at 08:12:17AM +0100, Jo wrote:
>>>> Looking at the CRAB data, most of the abbriviated streets look
>>>> like "A. Coolsstraat".  Where the "A. Cools" is the name of a
>>>> person.
>>>
>>> But do you know that in this case, the name of the street is his name.
>>> I don't know what the A in A. Coolsstraat stands for, so let's say it
>>> stands for the equivalent of "Avenue". Then it would be Avenue
>>> Coolsstraat. And we don't know if A. Cools is simply Avenue Cools, or
>>> Alfons Cools.
>>
>> Note that it already has "straat" in it's name, which is street.
>> Most streets have something like "straat" or "laan" or something
>> like that in their name.
>>
>> It's ussually obvious for us that it's the name of a person.
>>
>> There are also a whole lot of other cases that are easier to deal
>> with like "O.L. Vrouwstraat" which should get corrected to
>> "Onze-Lieve-Vrouwstraat", or "St.-Theresiastraat" to
>> "Sint-Theresiastraat".
>>
>> But I'm not sure what to do with streets that are for instance
>> spelled wrong.  For instance I see streets like "Sint Foo", which
>> really should be "Sint-Foo".
>>
>>>> It's currently also
>>>> abbreviated in osm and and tools like osmose don't even seem to
>>>> give a warning about that.
>>>
>>> Does Josm? If not- it sounds like it's something to code into their
>>> validator.
>>
>> I think I've seen osmose do thing like that, but neither is giving a
>> warning for that street.
>>
>>
>> Kurt
>>
>>
>> _______________________________________________
>> Imports mailing list
>> Imports at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/imports
>
>
>
> _______________________________________________
> Imports mailing list
> Imports at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports



More information about the Imports mailing list