Hi,<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 26, 2012 at 12:54 AM, Paul Norman <span dir="ltr"><<a href="mailto:penorman@mac.com" target="_blank">penorman@mac.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


I happened across an import of Fresno castradal data from mid-2010 in the<br>
Fresno area. <a href="http://www.openstreetmap.org/?lat=36.77&lon=-119.81&zoom=15" target="_blank">http://www.openstreetmap.org/?lat=36.77&lon=-119.81&zoom=15</a> is<br>
the general area but I haven't fully explored the extents. For a view of the<br>
data, see <a href="http://maps.paulnorman.ca/imports/review/fresno.png" target="_blank">http://maps.paulnorman.ca/imports/review/fresno.png</a><br>
<br>
</blockquote><div>A few observations: <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">1. It is castradal data. The consensus is against dumping castradal data<br>



into OSM.<br></blockquote><div><br>I am not aware of such a consensus - consensus among who? Is it documented? I would expect such a consensus to appear in the Import Guidelines but it doesn't. <br>Or do you mean there's a consensus against dumping data into OSM in general? If by 'dumping' you mean 'importing without consulting the community and without giving proper thought to attribute mapping and generalization / normalization of geometries' then yes, I'd say there's a consensus against doing that. I don't see why we would not cherry-pick useful and good cadastral data for import into OSM, however. It may be our only source of things like building outlines (are those generally in cadastral data in the US?) or address data in many parts. <br>

<br>I don't mean to be nitpicking here, I just want to clarify what this consensus actually is so people looking for guidance on importing in the future can be more fully informed.<br><br></div><div>[...] <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

8. There are duplicate nodes where data was imported on top of other data.<br>
For example, <a href="http://www.openstreetmap.org/browse/node/768314177" target="_blank">http://www.openstreetmap.org/browse/node/768314177</a><br>
<a href="http://www.openstreetmap.org/browse/node/767799968" target="_blank">http://www.openstreetmap.org/browse/node/767799968</a><br>
<a href="http://www.openstreetmap.org/browse/node/767770150" target="_blank">http://www.openstreetmap.org/browse/node/767770150</a><br>
<br>
With all of these problems I cannot think of any ways to fix the problems<br>
short of reverting the import. The tagging problems could be fixed by a<br>
script but the inherent problems of castradal data cannot be fixed without<br>
essentially deleting most of the import anyways.<br></blockquote><div><br>Are these problems inherent of cadastral data in general, of this dataset in particular, or of the way this import was conducted? <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">


<br>
I propose to delete unmodified objects from this import. I will attempt to<br>
preserve areas like schools and fix them if possible. It should be possible<br>
to keep most of them but I won't be able to be sure until I get into the<br>
removal.<br></blockquote><div><br> The list of issues is long enough and the issues serious enough to warrant a revert.<br></div>What I'm missing from this list is the issue I consider to be the most serious, which is that this user apparently has not consulted with anyone in the community about this import. Or has he/she?<br>

<br></div>-- <br>martijn van exel<br>

</div>