<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div>This data is definitely very up-to-date.  It is used by the county to impose property taxes, so it has to be up-to-date.  They offer new files weekly.<br>
</div></div></blockquote><div><br>problem is how can you convert the weekly updates into osm updates? You can't delete all data and upload again the next week.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="gmail_quote"><br><div>I basically just want the address info.  Having the parcel polygons is a bonus, but if it proves to be too difficult to maintain I could just move the data to the ways as an interpolation.<br>

<br></div></div></blockquote><div><br>just address data seems reasonable. It shouldn't change that much and easier to maintain.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="gmail_quote"><div><br>I don't know, I hope I can run a script regularly to provide a list of changes, and take it from there.  But worst case scenario I guess I can just remove everything.  Which gives me an idea.  I guess I should add a hcparcel:verified=no tag to everything I import.<br>

<br></div></div></blockquote><div> adding a tag like that is useless. everyone can change tags but doesn't have to when data is changed. It has zero information value as soon as others work on the data. same problem with tiger_reviewed=no some mappers use it others don't. any way modified if kind of reviewed but no one can tell how much of a review was done.<br>
If you need anything locked add a tag to a changeset. this can't be changed. <br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="gmail_quote"><div><br><br><div class="gmail_quote">On Mon, Sep 21, 2009 at 1:28 PM, Frederik Ramm <span dir="ltr"><<a href="mailto:frederik@remote.org" target="_blank">frederik@remote.org</a>></span> wrote:<div class="im">
<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
Anthony wrote:<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Any other suggestions?  Objections?  <br>
</blockquote>
<br>
Just my usual one: Please make sure that where you have polygons
sharing a common border, create an individual way in OSM for this
border and use a multipolygon relation for each of the neighbouring
parcels so that they may share the same way and nodes, rather than
importing two sets of nodes on top of each other (one for parcel A, the
other for parcel B).</blockquote></div><div><br></div></div></div></div></blockquote><div><br>another suggestion. don't make the same mistake as tiger, Massgis, PGS coastline ... imports and tag individual nodes if they are members of a way.<br>
don't add too many tags which have no use for osm and can be easily looked up in the source data. also consider to add some less useful tags to the changeset instead.<br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
_______________________________________________<br>
talk mailing list<br>
<a href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/talk" target="_blank">http://lists.openstreetmap.org/listinfo/talk</a><br>
<br></blockquote></div><br>