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

Serge Wroclawski emacsen at gmail.com
Mon Jul 22 20:14:06 UTC 2013


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



More information about the Imports-us mailing list