[Imports] [Imports-us] Palo Alto, CA Building Outlines import

[Jason Remillard]

Hello

Some general thoughts on building imports, since these two issues seem
to keep coming up.

For buildings, the long term maintenance plan is the same. Plan A, is
that in N years time, the area has enough mappers that the data is
being maintained like any other osm data. If Plan A, does not work out
because the area does not have enough mappers, the 2nd import is
pretty straight forward. You pull the original source data out, find
buildings that have been removed from OSM. Then in the new data
source, find buildings that are missing from OSM but have not been
removed from the first data set. That way, if somebody removes a
building in OSM, it does not get put back in on the second import. It
is always the same answer for building imports, so I think we can stop
asking importers about this.

We did a big building only import in MA this Spring. The addresses
were not available, and 1/3 of the states buildings were already
imported in 2010. At least for me, having the building has motivated
me to collect POI's and addresses that I was not previously doing.
Since the import, the JOSM validator has been pointing out places
where the roads and buildings overlap. So far, 98% of the time, the
imported road has been wrong per the Bing imagies. The buildings are
also improving the road data.

Also, at of this present moment in time, it is actually easier/better
to import the buildings first because that is the only thing that
Paul's address merge code supports. We should stop assuming that
everybody is going to be writing this code from scratch, and asking
for combined address/building imports. Honestly, I don't see why
anybody doing an address import going forward would not be looking
very closely at Paul's address merge code. If we end up teaching
address merge how to also do building imports, we can change our tune,
but right now, it is easier to put the buildings in first because
that's what address merge wants.

Thanks
Jason,





On Mon, Jul 22, 2013 at 4:14 PM, Serge Wroclawski <emacsen at gmail.com> wrote:
> On Mon, Jul 22, 2013 at 12:00 PM, the Old Topo Depot
> <oldtopos at novacell.com> wrote:
>
>> The LWG has not seen this, as I was not aware of that requirement, and
>> assumed the Import US group provided comprehensive guidance.
>
> It's not a requirement except that I don't think any of us have the
> experience to read a license like that and understand it.
>
> Legal wording is a bit like code- thinking you can read it without a
> legal background is a mistake, and since there are lots of clauses,
> I'm wondering if someone with a legal background has taken a look at
> it.
>
>> If consensus is that building outlines are not
>> useful without addresses, please explicitly state that now to save time and
>> effort.  Again, I am not proposing individually adding address points; this
>> proposal is for building outlines (and perhaps land use updates) only.
>
> It's my view that building outlines without addresses aren't worth it,
> but I'm not stuck in my ways, if someone has an argument of why
> they're useful, I'd like to hear it. I don't speak for everyone,
> either.
>
>> WRT to PA land use, those polys are already in the OSM DB, and many appear
>> rather rough.
>
> I think Paul removed a large amount of land use from California.
>
>> The city has a reasonable set of shapes, for example, there
>> are about 56 parks, and it seems useful to improve them where possible.  If
>> the plan is to remove them from OSM across the board, I will drop the idea.
>
> Do the parks have names, or can we do some kind of conflation of park
> locations against landuse and come up with park outlines with names?
>
>> On the subject of including ids and future updates, the idea that ids are
>> not very useful appears to be in conflict with the notion of continuing
>> maintenance.  The IDs are apparently persistent, and therefore are useful
>> for future update efforts.
>
> It's understandable that the two ideas appear in conflict, but they're
> not, and here's why:
>
> We need some kind of plan for update. One time imports, with no
> consideration made to maintenance is one of the biggest reasons that
> imports have such a bad reputation in OSM. If we're to fix that
> reputation, we need to address the issue head on.
>
> So then the question is "How do we do updates?"
>
> It's obviously very tempting to use the external dataset source_id's
> as a mechanism, but ultimately, the problem with that is, to put it
> bluntly "It doesn't work". It doesn't work for a few reasons. First,
> even if the data source uses consistent object IDs, you can't know for
> sure that an OSM user won't touch those object IDs on the OSM side.
> This is more than just a theoretical situation- when bot-mode was
> dealing with TIGER tags, I saw a lot of tiger tags which had been
> edited in some way or another. The end result is that the IDs from OSM
> are not a reliable source.
>
> The next problem is that you will invariably end up with data not from
> your import. A user will make a building trace, or a user will remove
> a building when it's demolished, etc. So your conflation process will
> need to handle these cases. And since you're now going to need to
> handle these cases of buildings w/o a building ID (using the geometry,
> or address, if available, then the question really is why do you need
> the building ID?
>
> There's a third problem with imported data with an external source
> tag, one that's hard to describe, but I've seen it very often... When
> an object in OSM has the feel of another dataset, users appear more
> hesitant to touch it. That means we lose out on mapper resources, and
> that's bad.
>
> So, if possible, we've been exploring ways to do the conflation task
> using information such as the geometry of the polygon, or address, or
> name, or some other information that would be the same whatever the
> source was.
>
> Jason put it really well once when he said (and I'm paraphrasing) "A
> good import is indistinguishable from normal mapping."
>
>
> Again, none of this is law or anything, but it's the result of a lot
> of thought by folks like myself, Paul, Ian, Jason, and others who have
> made imports, especially bad ones.
>
> - Serge
>
> _______________________________________________
> Imports-us mailing list
> Imports-us at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/imports-us