I wanted to post this to the mailinglist but for some reason it’s blocking me. So I’ll just post it here.
A few weeks ago there was talk about an iPad editor and that we should
instead work on an html5 editor because it would have more forward
compatibility. Inspired by this idea I set off to make an actual html5
Tada! The editor uses SVG which is pretty well supported in modern
browsers. Nodes are rendered as and ways are rendered as .
still very rough around the edges, selecting nodes and ways shouldn’t be as
hard as it is now.
So here’s the good news:
It works in Firefox, Safari & Chrome (though Firefox works the best). I
didn’t even bother testing it in IE.
Performance is surprisingly good, especially on Chrome.
It renders on the iPhone and presumably also the iPad!
It is possible to style the editor directly with css. It should be
fairly easy to make them look identical to their bitmap counterparts.
But the bad news is that it’s impossible to control the editor on the
iPhone. This is because all zooming and dragging operations are hijacked by
Safari for controlling the browser viewport. I haven’t found a way to
Is there any interest in making this a full-fledged official shiny html5
editor? I know the community isn’t very liberal towards new editors. So I’m
just going to throw this out there and see what you guys have to say.
Perfect! I wanted to do a similar project yet due to my limited time, I haven’t started. While my time still is rather limited, I can’t do much programming. But I can support you with ideas, critism, suggestion, tests and so on. Anything which doesn’t need much time.
So first, why did you choose SVG? I would have choosen Canvas instead. I haven’t really checked but guess Canvas are much simpler and need much less download capacity and performs better. Just think in a tight area there might be thousends of elements be downloaded and displayed. Openlayers already uses Canvas (http://openlayers.org/dev/examples/canvas.html) so it might be possible to share knowledge.
The reason I chose svg is that it’s more suitable for rendering vector data. Atleast I think, that’s what the internet says.
It’s also easier because I don’t have to worry about which ways to render, hopefully the browser does that for me in an efficient way. We should do a canvas version to see which performs better.
With rendering you mean converting OSM data into SVGs? I don’t think so.
Again I think browsers can render Canvas faster.
That would be perfect. I’ve played around a little with http://paulwagener.nl/osm/editor.xhtml, as soon as zoom level goes down your script uses too much time. With level 16 SeaMonkey starts complaining.
Could you tell me/us from which database (format) you start and if you convert to a single SVG or multiple.
I haven’t tested SeaMonkey but with Chrome and Firefox I haven’t had any performance problems. It only starts slowing down when it displays a significant chunk of downtown london, and even then it’s usable.
The svg editor doesn’t zoom to the correct level. It’s just a hardcoded value.
The CSS is just like HTML css. In fact it IS HTML CSS. I’ve given all ways and nodes classes according to their tags. A quick look through the DOM should reveL their pattern.
Why the inputs aren’t editable is black magic to me. Seems like they should work.
Seems you convert tags like “buildings=yes” to “building-yes”. Could change that to “building_yes”? It might be that “-” is contained in a tag. Isn’t it possible to convert “name=…” to the name statement or doesn’t SVG items have a name?