[Imports] Review of proposed spanish castrade import (Avila.osm)

[Jaime Crespo]

El 25/03/2012 08:19, "Paul Norman" <penorman at mac.com> escribió:
> Wikipedia indicates that the population of Avila is 58k.
>
> As this one file would increase the number of relations in the database by
> 5% (and the number of multipolygons by 10%), have you spoken with the
> sysadmins to see what the impact would be on the OSM servers?

That is why we are here even before the tool is completely developed and
before any upload has been done.

> If one town of 58k were to increase the number of multipolygons by 10%, I
> could see the import easily doubling the total number. What impact would
> this have on processing times for the various tools?

Yes, this should be reduced, and we have seen some issues where it can be
done. When I say we, I refer to the Spanish list, where people from several
areas are providing feedback to the original developers (not me).

> Overlap:
>
> Frequently one multipolygon is overlapping another. An example of this is

> found at (40.6615, -4.6895). Here one MP (-1289355) covers the entire lot
> with landuse=farmyard while a smaller one (-1269673) covers the
non-building
> part of the lot, overlapping with the first. The top four are tagged
> indentically.
> Breaking lots into too small areas:
>
> http://maps.paulnorman.ca/imports/review/avila1.png illustrates one
example
> of this problem. Selected is one MP for a lot with 5 MPs inside with
> landuse=residential overlapping with the big one for the lot. Why so many?
>
> The small block of 5 houses below has 31 landuse=residential
multipolygons.
> It should only have one for the entire block.
>
> Multipolygons with no styles on them

Some blocks have a different height (or no height, but they are not
ground-level, so still buildings).

Some overlapped areas are landuses or groups of blocks with the same
addreses.

If it is not the case, they really share the same attributes, it is an
application error (it should be corrected, already has been on later
versions, or they shoud be labeled with a fixme tag for manual checking
before importing).

In my opinion, landuses with no different tagging should be merged into a
single area.

> Object Types:
>
> landuse=farmyard seems to be applied to areas that are not farmyards. For
> example, the buildings at (40.6605, -4.6921) are tagged as being farmyard,
> but they're in the middle of a city block with no farms in the area.

Yes, it happened to a city I converted, too. It seemed to be an error on
the tag conversor and on a new try with a newest version I did it did not
happen anymore to me. There are still some mistagging that I think it could
be fixed.

> power=tower is being used for what appear to be power=pole

I will pass it to the developer.

> When I proposed my surrey address import to the list the consensus was
that
> addr:country was not needed with working boundary relations.

Perfect. Easily done.

> catastro:surface, catastro:surface:built, catastro:surface:overground:
What
> are these tags indicating?

Those are debugging tags, as far as I know we told them not to use own tags
anymore except the attribution ones: source & source:date (they should not
be shown in current versions).

> natural=tree: A lot of these nodes are located in the middle of roads or
in

This is not uncommon in Spain, at least.

> other places which would be absurd like the middle of a sports field. The
> imagery agrees with the other data and indicates the trees are wrong.

Will check it. These are the kind of things that either should be checked
by local area people or discarded for transformation.

> addr:*=*: There are already address nodes in the city. How do you propose
to
> conflate these with the data you want to import?

Manually. Again, this is not an import.

Addresses are something that personally I have not clear. Is it better to
have the node at the entrance or to the assigned block(s)? We can even get
both, but then we would duplicate the data...

> Conclusions:
>
> There are many significant issues with this data that render it only
> suitable as a background layer for tracing from and not a direct import.
The
> issues of excessively splitting areas up that are present with most
property
> lot data sources are even worse here, using an absurd number of objects to
> represent what a mapping tracing would only use 1-2 for.
>
> Looking at my data increases the conviction that the French and American
> communities have been right in rejecting parcel lot data. It is just not
> suited for OSM.

Objects can be merged. There is still much improvement here. The question
is: where is the acceptable limit?

> I routinely work with large .osm files in JOSM and work with
gigabyte-sized
> .osm files. The slowness I found when working with this file surprised

I think the tool should be flexible enough to export only what we wanted
(it actually is).

Parcels could be used as a basis for bigger landuses. We could transform
source data into anything we want.

So we agree in most of the points.
I will see if I can send you a more up to date exported file.

The problem is that this data has been available for almost a year with a
CT compatible license and we have already seen crapy half-imports. I would
prefer a community-controlled process (and that includes you!) with
automated quality tools and manual intervention that individuals doing
whatever they want.

I understand the problem here is complexity, not size. And we already knew
that.

My fear is (apart from the issues already shown and other that will arise):
Are we rejecting data just because the API limits, hardware bounds, editor
capabilities that will be acceptable 3 years from now? What is the limit
for micromapping? I hope you understand my desire to make OSM greater for
every possible use.

Of course, I understand your concerns, too, which are the same as mine.
--
Jaime Crespo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20120325/f51ab85c/attachment.html>