Guys, <br>This sounds like a nice application. I think there is a general need for some type of POI database, even where you dont have the location yet. Streetname, town, general lists could be loaded and compared and linked to osm..<br>
<br>But where is this hotel data? I would like to see a sample. Can you just paste the first 10 lines into the mail so we know what we are dealing with?<br><br>mike<br><br><div class="gmail_quote">On Thu, Jan 28, 2010 at 6:33 PM, Greg Troxel <span dir="ltr"><<a href="mailto:gdt@ir.bbn.com">gdt@ir.bbn.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Pieren <<a href="mailto:pieren3@gmail.com">pieren3@gmail.com</a>> writes:<br>
<br>
> On Thu, Jan 28, 2010 at 1:37 PM, Greg Troxel <<a href="mailto:gdt@ir.bbn.com">gdt@ir.bbn.com</a>> wrote:<br>
><br>
>> I've been thinking about how to handle maintenance of imports; so far<br>
>> osm has tended to import once and then just edit.  My suggestion is to<br>
>> put whatever database primary key you use on the node, and to be able to<br>
>> look at the node and tell which import was done, which really means the<br>
>> internal date or whatever identifier of your database extract.<br>
<div class="im">><br>
> But what happens if someone replaces your imported node with a new one or<br>
> the node is deleted or someone just changes your primary key for fun ?<br>
> I think it would be better to keep the node_id or way_id (building) in your<br>
> own database and check regularly if your element is still at the right<br>
> location (with some tolerance) with the right tags (with some tolerance) .<br>
> Then if the POI has been removed, check if the same one has not been<br>
</div>> recreated around. If yes, just refresh the node_id in your db. If not,<br>
> recreate the POI or revert the deletion. The link between your db and OSM is<br>
> the lat/lon, not an id which is not guaranteed in time.<br>
<br>
The basic principle that I think should be followed is that if imported<br>
data is changed by a user, then that change should not be blindly<br>
overwritten by an import process.  That doesn't mean "node not updated"<br>
- if a user moves a hotel point and the hotel company has a new phone<br>
number and verifies (perhaps programmatically) that the old phone number<br>
is still there, then it's fine to automatically edit it.  But it would<br>
be broken to overwrite the location.<br>
<br>
If a user deletes a node and replaces it, then the next import should<br>
flag that as needing manual intervention.  And users shouldn't do that -<br>
they should edit the node.<br>
<br>
<br>_______________________________________________<br>
Imports mailing list<br>
<a href="mailto:Imports@openstreetmap.org">Imports@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/imports" target="_blank">http://lists.openstreetmap.org/listinfo/imports</a><br>
<br></blockquote></div><br>