[OSM-dev] JSON/GeoJSON output format for 0.6 api
nospam-abuse at bloodgate.com
Thu May 28 17:35:22 BST 2009
On Wednesday 27 May 2009 15:20:26 Richard Fairhurst wrote:
> Ed Loach wrote:
> > Is there anywhere though that z13 Yahoo imagery is of any use?
> Sure. It's ok for lakes, woods, built-up areas, that sort of thing.
> I'm just looking at somewhere near Rhayader and it's pretty useful.
> > I like Shaun's suggestion of defaulting to z17 and let users zoom
> > out.
> So would I, if I too lived somewhere with more people than sheep. The
> problem with that is when (say) you want to edit a lake somewhere in
> mid-Wales, you navigate to it using View as per usual, then click
> "Edit", and that zooms in to somewhere with absolutely no data. At
> which point you send a message to talk@ saying "where has the data
> gone I blame Potlatch pls to revert the changeset omgwtfbbq" - I'm
> not joking - and we all get a headache.
> From a usability point of view the View and Edit tabs should be
> equivalent - i.e. wherever you're viewing, clicking 'Edit' preserves
> the bbox.
> We currently have a JS alert at z1-z10 saying "zoom in to edit map",
> and we italicise the tab to show that it's not clickable. (It should
> really be z1-z12, I'm not sure why it isn't.)
> This is good. If it were context-sensitive depending on the amount of
> data in the area, it would be wonderful.
Well, one could fetch the data at z17, see it is below some
$ARBITRARY_THRESHOLD, zoom out to z16m, fetch again, and if still below
$THRESHOLD, repeat it until either there is too much data (display
message) or the user-requested zoomlevel was reached.
Might fetch more data (double fetching) in a few cases, but might spare
huge requests for dense areas.
All the best,
Signed on Thu May 28 18:33:50 2009 with key 0x93B84C15.
Get one of my photo posters: http://bloodgate.com/posters
PGP key on http://bloodgate.com/tels.asc or per email.
"Memory is like an orgasm. It's a lot better if you don't have to fake
-- Seymore Cray, on virtual memory
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 481 bytes
Desc: This is a digitally signed message part.
More information about the dev