[OSM-dev] OpenLayers, GeoRSS and annotations demo
nick at hogweed.org
nick at hogweed.org
Thu Jun 15 22:03:47 BST 2006
On Wednesday 14 June 2006 16:35, Dan Karran wrote:
> - I don't think you should give end users the decision of what should
> go to OSM and what shouldn't - my view is that that should be handled
> by some logic behind the scenes. Users shouldn't be faced with that
> choice I don't think. When I was faced with that option I wasn't sure
> which I should do.
Probably a good idea.
> - Adding annotations should provide some visual feedback.
Currently an icon appears at the point that was clicked. However I agree these
could be confused with ordinary OSM features, a pushpin like graphic - like
the OpenLayers default - would be better.
> - Leading on from that, how are you going to deal with annotations
> that people add to OSM? If they add them, but you're only going to be
> pulling in the OSM data every month using the planet.osm, how will
> that work? Perhaps store in your database the ID of the object created
> in OSM so that they're linked, then when changes are made to the
> version in your site, you can push those back to OSM.
The only change to annotations on my site which would affect OSM as a whole
would be deletion of the features. I don't intend to add facilities such as
the ability to move an annotated feature - not yet anyway.
> You'd also need
> to regularly check the other way round as well - what happens when
> something changes in OSM that also exists on your site?
That is an intrinsic problem with using planet-derived data, but that's really
the only option at the moment. I'd imagine when OSM grows and has more server
power, it will be sensible for OSM rendering clients to send OSM a map
request, grab the raw XML and render locally, thus always keeping up to date.
Sidetracking slightly, it's probably better that even in this hypothetical
future scenario, clients of OSM data work off a copy of the OSM server which
is write only, as the versioning stuff slows down database queries
significantly, particularly for ways.
> Sorry for the braindump, I'm curious about how these things should be
> handled in OSM clients.
More information about the dev