HTML5 Editor proof of concept

wyo · 2010-12-08 09:50:15

E-Malte wrote:

paulwagener wrote:
As for the key-values
But I would prefer classes for that, as you can give multiple classes to an Element and I don't like CSS's handling of attributes.

I prefer classes as well. First I though the key/value pair could be split into 2 classes but then the relationship gets lost. Maybe 2 classes (class=<key>, class=<key>-<value>) are possible. Yet we easily can postpone this until later.

Another question, would be possible to compute all positions (coordinates) as in zoom level 18 and then zoom the map to the correct level by using transform and clipping? Then each element has to be computed just once. If yes it might be possible to have these preprocessed on a server and directly retrieving SVG g-elements.

Do we agree in having a separate g-element for each way, containing name, points and tags of a way? Same for nodes, yet what about relations?

Wyo

E-Malte · 2010-12-08 21:49:03

wyo wrote:

First I though the key/value pair could be split into 2 classes but then the relationship gets lost. Maybe 2 classes (class=<key>, class=<key>-<value>) are possible. Yet we easily can postpone this until later.

In fact you have to write all classes into one attribute, so it would be more like class="k_<key> kv_<key>_<value>" or something similar. Although you could have several options to style it. Osmarender does it this way: class="<key>-<value>" [1].

Another question, would be possible to compute all positions (coordinates) as in zoom level 18 and then zoom the map to the correct level by using transform and clipping?

This is actually possible without zooming and clipping by using the viewBox Element or if it should be more complex with a transform-Element.
In my opinion the view Box would be better for this.
But it wouldn't be possible to keep the same projection when scrolling far away, if you choose a viewport-depening projection (which usual tiles are). For smaller areas you can ignore it, and for larger ones you could choose a projection depending not on the viewport.
When zooming in or out it should be possible to set some kind of zoom level to an Element, so that the style should be dependent on the zoom level...

Another solution for all that would be the usage of OpenLayers, as its Vector-Layer-Feature uses SVG itself, and you can access all attributes...

[1] See i.e. defs-Element of this Osmarender-Stylesheet: http://svn.openstreetmap.org/applicatio … es-z17.xml

Malte

paulwagener · 2010-12-09 00:06:46

You can solve the different styles for different zoom levels by adding the zoom information as a class to a container element and then use selectors like ".z18 .keyvalue {}"

wyo · 2010-12-09 08:47:49

E-Malte wrote:

Another question, would be possible to compute all positions (coordinates) as in zoom level 18 and then zoom the map to the correct level by using transform and clipping?
This is actually possible without zooming and clipping by using the viewBox Element or if it should be more complex with a transform-Element.

Sorry I'm not familiar with the viewBox element.

E-Malte wrote:

But it wouldn't be possible to keep the same projection when scrolling far away, if you choose a viewport-depening projection (which usual tiles are). For smaller areas you can ignore it, and for larger ones you could choose a projection depending not on the viewport.

Well transforming (maybe also viewBox) could be handled as UTM coordinates are handled, just apply different transformation to different UTM zones. Of course this means the SVG has to be devided into these zones. BTW I don't think people will edit the map in any of these levels albeit it might be good to keep an eye on this issue.

E-Malte wrote:

When zooming in or out it should be possible to set some kind of zoom level to an Element, so that the style should be dependent on the zoom level...

As Paul already said, styling can depend on zoom levels.

What's more interesting is, how to limit the stream of downloaded elements. As we currently seen the API is completely overloaded. Therefore we need to be able to filter elements either according to visiblity (styling) and/or to user requests. Also we need a caching structure which stores retrieved but invisible elements. Maybe this could be done inside the SVG itself.

Where are the rules for, which elements are retrieved in each level. I'd like to have this information combined into the styling. In other words whenever a style for an element in a level doesn't exist, it's not retrieved from the DB. Is it possible to check for the existens of a style and then set up a filter accordingly?

E-Malte wrote:

Another solution for all that would be the usage of OpenLayers, as its Vector-Layer-Feature uses SVG itself, and you can access all attributes...

Can you explain this more?

Wyo

E-Malte · 2010-12-09 16:47:34

The viewBox-Attribute is an attribute which can be applied to the svg-root-Element.
It's used like: "<svg ... viewBox='<x> <y> <height> <width>' >..</svg>" where those coordinates are handled the same like in the rectangle. This viewBox-rectangle is then zoomed into the drawing area (either set by height and width on the svg-root-Element or otherwise the whole "drawable" browser-window).
SVG-Spec to viewBox with some examples: http://www.w3.org/TR/SVG/coords.html#ViewBoxAttribute

If I understood UTM correctly, could be probably used as the SVG-Transformation only includes:
- scaling
- translation
- rotation
- skewing
- combinations of it and everything else which can be displayed by an affine transformation in the style of
X' = ( a b ) * X + ( e )
( c d ) ( f )
which is used in SVG this way: "<someelement transform='matrix(a, b, c, d, e, f)' ... />"
Wikipedia link to affine transformations: http://en.wikipedia.org/wiki/Affine_transformation
SVG-Spec to transform with further explaination: http://www.w3.org/TR/SVG/coords.html#TransformAttribute

I guess if one recalculates the matrix after every translation (moving) an scaling (zooming) of the map, it should be possible to display them without replacing the original coordinates.

What's more interesting is, how to limit the stream of downloaded elements. As we currently seen the API is completely overloaded. Therefore we need to be able to filter elements either according to visiblity (styling) and/or to user requests. Also we need a caching structure which stores retrieved but invisible elements. Maybe this could be done inside the SVG itself.

Set CSS-Style: "display: none" to a specific class or id?

Where are the rules for, which elements are retrieved in each level. I'd like to have this information combined into the styling. In other words whenever a style for an element in a level doesn't exist, it's not retrieved from the DB. Is it possible to check for the existens of a style and then set up a filter accordingly?

This should be possible by some programming work, but it couldn't send its result to the server, as it just replies all elements in a current bounding box.

OpenLayers is applicable to draw OSM-files onto its Vector layer. Probably one can use it to display and modify the OSM-Data.
This (quite old) exaple shows the basics of what I mean: http://openlayers.org/dev/examples/osm-layer.html
But it's not fully working anymore, as the referenced tiles are not available anymore, and it uses API 0.5...

Malte

wyo · 2010-12-10 08:51:04

E-Malte wrote:

I guess if one recalculates the matrix after every translation (moving) an scaling (zooming) of the map, it should be possible to display them without replacing the original coordinates.

Fine, this makes moving (panning) and zooming much easier.

E-Malte wrote:

What's more interesting is, how to limit the stream of downloaded elements...
This should be possible by some programming work, but it couldn't send its result to the server, as it just replies all elements in a current bounding box.

As even Potlatch2 shows, retrieving all elements in levels > 15 are almost impossible. Data has to be reduced somehow. Therefore I started another thread so API 0.7 will have this features. So far API 0.6 can filter multiple elements yet I don't know much but the API isn't designed for as many elements as the SVG-Editor possibly needs.

Wyo

unxed · 2011-06-24 14:56:00

Any news on this editor?

paulwagener · 2011-06-28 13:43:41

unxed wrote:

Any news on this editor?

Nope, as a proof of concept it is pretty much done. If a lot of people are interested in making this something full-fledged then I'll start working on it again.

Janjko · 2011-09-20 11:45:19

I need this, I'm stuck on a java-flash-free machine

duncaninnes · 2012-07-12 10:40:49

The current state of Flash would suggest that working on a fully fledged HTML5 editor now would not be a waste of time.

There isn't a browser out there (I'll gloss over IE < 9 for now) that doesn't have good HTLM5 support. Flash won't die a death any time soon on the web, but the sooner projects turn to HTML5 the better.

Being a Sys Admin, I'm of little use other than for testing. But for now I'll just add my voice to the "Please continue this development" crowd.

D

Richard · 2012-07-13 12:29:07

Take a look at this posting and the work-in-progress here!

scai · 2012-07-13 13:09:08

Nice, looks promising.

Announcement

#26 2010-12-08 09:50:15

Re: HTML5 Editor proof of concept

#27 2010-12-08 21:49:03

Re: HTML5 Editor proof of concept

#28 2010-12-09 00:06:46

Re: HTML5 Editor proof of concept

#29 2010-12-09 08:47:49

Re: HTML5 Editor proof of concept

#30 2010-12-09 16:47:34

Re: HTML5 Editor proof of concept

#31 2010-12-10 08:51:04

Re: HTML5 Editor proof of concept

#32 2011-06-24 14:56:00

Re: HTML5 Editor proof of concept

#33 2011-06-28 13:43:41

Re: HTML5 Editor proof of concept

#34 2011-09-20 11:45:19

Re: HTML5 Editor proof of concept

#35 2012-07-12 10:40:49

Re: HTML5 Editor proof of concept

#36 2012-07-13 12:29:07

Re: HTML5 Editor proof of concept

#37 2012-07-13 13:09:08

Re: HTML5 Editor proof of concept

Board footer