HTML5 Editor proof of concept

wyo · 2010-09-19T19:20:45.000Z

paulwagener:

If you comment out line 40 and re-enable line 42-45 you can even do without php.

PHP is no problem for me.

Could you change the web page so the map an the editor are next to each other. This would allow for a much better overview.

So far you style the vectors all in the same color, could you style at least some like they are done as in Potlatch? Just set up a starting css and I’ll all more colors according to the tags.

Wyo

paulwagener · 2010-09-19T22:37:29.000Z

I’ve enabled the ability to style ways and nodes according to their tags.

wyo · 2010-09-20T16:51:09.000Z

paulwagener:

http://trac.paulwagener.nl/browser/PaulWagener.nl/osm

Are these the right sources? My page looks completely different.

Otti
PS I tried to reach you by email without success.

paulwagener · 2010-09-20T22:02:24.000Z

They were indeed different. For some reason trac got out of sync. Fixed now.

wyo · 2010-09-21T17:30:14.000Z

paulwagener:

They were indeed different. For some reason trac got out of sync. Fixed now.

And my error was I didn’t saw the “original format” download link. See now http://www.orpatec.ch/osm/editor/editor.xhtml

I’ve commented out “parentNode.removeChild” in loadEditor and some other changes so that map and editor are both visible. Seems there’s a problem with exact sizing of the vectors.

BTW is it possible to add a title element to show the actual zoom level on the +/- handle? Or is such a feature missing in OpenLayers?

wyo · 2010-09-21T17:38:16.000Z

Your “editor.css”, does it have a similar structure as in OpenLayer? Is the format anywhere documented?

wyo · 2010-09-21T17:41:04.000Z

BTW why can’t I mark and copy a text from the fields of a seleced node?

paulwagener · 2010-09-22T13:42:09.000Z

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.

wyo · 2010-09-22T19:55:38.000Z

paulwagener:

The svg editor doesn’t zoom to the correct level. It’s just a hardcoded value.

Well how difficult is it to make it match?

paulwagener:

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.

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?

What’s the meaning of the “null” class?

Wyo

wyo · 2010-09-23T16:11:59.000Z

wyo:

Could change that to “building_yes”? It might be that “-” is contained in a tag.

Scrap that, any map feature tag uses “_”. Unfortunaltely names (usually man made) do contain “-”. Yet names could be moved to the name statement instead of another class.

I’ve colored the vectors a little see http://www.orpatec.ch/osm/editor/editor.xhtml. It would help if the zoom level would match somehow and if the map could be moved around in a larger area.

Filling rectangles overlaps other buildings (see Tower of London). You have to add the inner/outer rules of the buildings.

Wyo

WBSKI · 2010-12-06T23:37:16.000Z

Great work! Seems to be working fine in Chrome! I am interested in helping out with this if you are still interested Paul

Cheers
Russell

wyo · 2010-12-07T09:39:10.000Z

WBSKI:

Great work! Seems to be working fine in Chrome! I am interested in helping out with this if you are still interested Paul

I’m equally interested in an SVG editor and have set up a project page (http://wiki.openstreetmap.org/wiki/SVG-Editor). I’ll collect any information about the project there.

Wyo

paulwagener · 2010-12-07T17:36:32.000Z

Nice to see there is still interest in it.

I’ve created a project on google code:
https://code.google.com/p/svg-mapeditor/

For everybody that wants to help out just send me a mail and i’ll add you to the project.

wyo · 2010-12-07T19:22:37.000Z

paulwagener:

https://code.google.com/p/svg-mapeditor/

Fine. I think it’s easier for any visitors to have the project info here in the wiki while the code, etc goes into google. Is that okay for you?

First lets discuss the concept, e.g. I’ve alter the internal organisation (g-element) of the SVG. Any objections (see http://wiki.openstreetmap.org/wiki/SVG-Editor))?

Another issue is adding the tag information as -, I’m not satisfied with this yet haven’t found a better solution.

I’ve set up my own test page (http://www.orpatec.ch/osm/editor/editor.xhtml) and added a CSS (http://www.orpatec.ch/osm/editor/editor.css) to colorize everything a little more.

Wyo

paulwagener · 2010-12-07T21:02:26.000Z

The Google project is purely for the code hosting so we can work with multiple people on it. I’ve deleted a few tabs to clear that up.

As for the key-values: We could just add each of them as actual attributes to the and and use the css attribute selectors to style them. I don’t know if this is allowed and could be problematic for keys that happen to overlap with the existing attributes.

Wyo: Could you send me a private message with your e-mail so you can merge your changes into the source?

E-Malte · 2010-12-07T21:52:55.000Z

paulwagener:

As for the key-values: We could just add each of them as actual attributes to the and and use the css attribute selectors to style them. I don’t know if this is allowed and could be problematic for keys that happen to overlap with the existing attributes.

In fact you have to introduce an own namespace then with valid DTD etc. But it should work with the arguments theirselves.
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.

wyo · 2010-12-08T08:50:15.000Z

E-Malte:

paulwagener:

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=, class=-) 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-08T20:49:03.000Z

wyo:

First I though the key/value pair could be split into 2 classes but then the relationship gets lost. Maybe 2 classes (class=, class=-) 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_ kv__” or something similar. Although you could have several options to style it. Osmarender does it this way: class=“-” [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/applications/rendering/osmarender/stylesheets/osm-map-features-z17.xml

Malte

paulwagener · 2010-12-08T23:06:46.000Z

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-09T07:47:49.000Z

E-Malte:

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:

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:

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:

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