<p>El 25/03/2012 08:19, "Paul Norman" <<a href="mailto:penorman@mac.com">penorman@mac.com</a>> escribió:<br>
> Wikipedia indicates that the population of Avila is 58k.<br>
><br>
> As this one file would increase the number of relations in the database by<br>
> 5% (and the number of multipolygons by 10%), have you spoken with the<br>
> sysadmins to see what the impact would be on the OSM servers?</p>
<p>That is why we are here even before the tool is completely developed and before any upload has been done.</p>
<p>> If one town of 58k were to increase the number of multipolygons by 10%, I<br>
> could see the import easily doubling the total number. What impact would<br>
> this have on processing times for the various tools?</p>
<p>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).</p>

<p>> Overlap:<br>
><br>
> Frequently one multipolygon is overlapping another. An example of this is</p>
<p>> found at (40.6615, -4.6895). Here one MP (-1289355) covers the entire lot<br>
> with landuse=farmyard while a smaller one (-1269673) covers the non-building<br>
> part of the lot, overlapping with the first. The top four are tagged<br>
> indentically.<br>
> Breaking lots into too small areas:<br>
><br>
> <a href="http://maps.paulnorman.ca/imports/review/avila1.png">http://maps.paulnorman.ca/imports/review/avila1.png</a> illustrates one example<br>
> of this problem. Selected is one MP for a lot with 5 MPs inside with<br>
> landuse=residential overlapping with the big one for the lot. Why so many?<br>
><br>
> The small block of 5 houses below has 31 landuse=residential multipolygons.<br>
> It should only have one for the entire block.<br>
><br>
> Multipolygons with no styles on them</p>
<p>Some blocks have a different height (or no height, but they are not ground-level, so still buildings).</p>
<p>Some overlapped areas are landuses or groups of blocks with the same addreses.</p>
<p>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).</p>

<p>In my opinion, landuses with no different tagging should be merged into a single area.</p>
<p>> Object Types:<br>
><br>
> landuse=farmyard seems to be applied to areas that are not farmyards. For<br>
> example, the buildings at (40.6605, -4.6921) are tagged as being farmyard,<br>
> but they're in the middle of a city block with no farms in the area.</p>
<p>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.</p>

<p>> power=tower is being used for what appear to be power=pole</p>
<p>I will pass it to the developer.</p>
<p>> When I proposed my surrey address import to the list the consensus was that<br>
> addr:country was not needed with working boundary relations.</p>
<p>Perfect. Easily done.</p>
<p>> catastro:surface, catastro:surface:built, catastro:surface:overground: What<br>
> are these tags indicating?</p>
<p>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).</p>
<p>> natural=tree: A lot of these nodes are located in the middle of roads or in</p>
<p>This is not uncommon in Spain, at least.</p>
<p>> other places which would be absurd like the middle of a sports field. The<br>
> imagery agrees with the other data and indicates the trees are wrong.</p>
<p>Will check it. These are the kind of things that either should be checked by local area people or discarded for transformation.</p>
<p>> addr:*=*: There are already address nodes in the city. How do you propose to<br>
> conflate these with the data you want to import?</p>
<p>Manually. Again, this is not an import.</p>
<p>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...</p>
<p>> Conclusions:<br>
><br>
> There are many significant issues with this data that render it only<br>
> suitable as a background layer for tracing from and not a direct import. The<br>
> issues of excessively splitting areas up that are present with most property<br>
> lot data sources are even worse here, using an absurd number of objects to<br>
> represent what a mapping tracing would only use 1-2 for.<br>
><br>
> Looking at my data increases the conviction that the French and American<br>
> communities have been right in rejecting parcel lot data. It is just not<br>
> suited for OSM.</p>
<p>Objects can be merged. There is still much improvement here. The question is: where is the acceptable limit?</p>
<p>> I routinely work with large .osm files in JOSM and work with gigabyte-sized<br>
> .osm files. The slowness I found when working with this file surprised</p>
<p>I think the tool should be flexible enough to export only what we wanted (it actually is).</p>
<p>Parcels could be used as a basis for bigger landuses. We could transform source data into anything we want.</p>
<p>So we agree in most of the points.<br>
I will see if I can send you a more up to date exported file.</p>
<p>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.</p>

<p>I understand the problem here is complexity, not size. And we already knew that.</p>
<p>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.</p>

<p>Of course, I understand your concerns, too, which are the same as mine.<br>
--<br>
Jaime Crespo<br>
</p>