On Sun, Nov 24, 2013 at 11:10 AM, Randal Hale <rjh...@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 rjh...@northrivergeographic.com > <mailto:rjh...@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 <k...@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@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/imports > > > > _______________________________________________ > Imports mailing list > Imports@openstreetmap.org > https://lists.openstreetmap.org/listinfo/imports _______________________________________________ Imports mailing list Imports@openstreetmap.org https://lists.openstreetmap.org/listinfo/imports
