Tags: ideas

anime

Future of OpenStreetMap API

I've been reading through the API v0.7 Brainstorm and came across the proposal for Segments. Which relates heavily to my previous post. I want go over some other observations/interests. Consider this constructive criticism, I don't know best; I've come from the outside and I'm looking in, this is the best time for me to write down what I see before being subdued to "the way things are."

OSM has provided some very powerful data primitives which provides many opportunities to place information on a map. This has lead to convention followed by support. A convention is proposed (sometimes approved) and it gets used; tools are later created to support this new convention, either to make it easier to edit or to display the information added. And people go all out with detail, mapping 3D Buildings.

This is a very powerful means for creating new content. Retrieving that content is equally important and this should be made easy and consolidated as possible so that every application can benefit instead of the specially built app (which I realize is unavoidable).

It is not that adding new primitives will magically get apps to support all content, what it does is give structure to the content so it is clear to the mapper how to formulate the data, and it is clear to the application programmer how everyone will format the data when that data is applicable to them.

OSM should be looking at the most pervasive conventions and figuring out how to simplify them. Time tables are simple, but what about lanes open specific hours or change directions in those hours? Turn restrictions are nice, but what about down to the lane. When a street has two names (number and name) what to do, especially when providing names in different languages.

Convention can best address some issues, but some conventions get very complex. Giving very precise definitions and updating editors to hide those details can work, other times proper primitives make convention standard and usable across many applications (err not the software).

Conclusion



I don't know what I'm talking about, I don't have any direct solution, it is not like I've put much thought into this. I just hope the community can take into consideration good solutions and not get caught up in "you can already do that" type of thinking. The details being added are going to make map editing more difficult, we need updates to editing software and the infrastructure which supplies the data.
anime

Criteria for Advance OpenStreetMap Editor Part 2

An advanced editor is an editor which makes it easier to edit a map. The reason is because the editor knows how to edit a map, if it just surfaces the primitive data that is a basic editor; with a basic editor it is easy to make changes but hard to describe the desired changes. Paint is a basic editor, one can add color to the canvas yet removing red eye is harder than in Photoshop.

A contributor doesn't want to create two squares which are related, they want to construct a building with a court yard in the center which has a portion of the building where first story is not part of the building but there is a second story connecting both sides. They want to state a left turn is not valid onto such and such road, not split a road and then make that statement.

When editing OSM data it is very challenging to make whole edits. Consider some stages of editing one might see with a road.


  1. Draw a road connecting two roads

  2. Name that road

  3. Split the road where speed limits change (add appropriate tags)

  4. Split the road where the number of lanes change

  5. Split the road where a turn restriction is needed

  6. Split the read where classification changes

  7. Split the road where surface type changes

  8. Split the way for new route (bus)


What is the problem here? As we increase the detail of a road the number of segments that must be maintained multiplies. A single road is segmented in so many different ways it is difficult to make corrections to a single property and maintain correct placement of all other properties. Remember each of these edits is made by different people at different times with different skill and knowledge of OSM. And I pity the contributor who now wants to correct a misspelling in the original submission of the road name.

JOSM is probably filled with plugins to assist in several/all of these tasks, but we want to create and advanced editor, not a power user editor. We have layers of data which must all fit into a single representation and the editor must take make the separation of data layout and information layout into its core. In fact, this is something which should be addressed all the way back in data retrieval; the majority of the time local information is all that is needed, retrieval of an entire bus route or highway can be of benefit.

This is by no means an easy approach to implement, the data analysis and the user-interface provide a number of challenges to help the user quickly make the changes they need. These challenges may not be work it to overcome, I just really like they simplicity in my mind which comes from having all the details worked out.
anime

Criteria for Advance OpenStreetMap Editor Part 1

I'm fairly new to OpenStreetMap. I joined about a year ago and have done a fair amount of mapping, so I'm not completely new. I haven't joined the community, there isn't any mappers in my area and even if there was I'm really not that interested in mapping. It is a means to an ends, I want to make it better so others will want to make it better so I can benefit from their work. Unfortunately this isn't a post about some cool new editor I've built or plugin I've created. It is just an armchair mapper who has all the answers and wants the world to know. And who may eventual get more involved.

This post is about what needs to happen to develop an advanced editor for OSM. This is not from the user perspective where we say "it is advanced if it is hard to use." I'm talking about an editor which knows how to edit OSM data and in doing so, makes it easy.

To start off I'd like to point to the talk "iD, a New Editor for OpenStreetMap". This talk is correct, it mentions giving suggested tags and issues with the "advanced" option where the user is left with a couple empty boxes to enter whatever they choose. He mentions the feature to draw an area... but OSM data doesn't have a concept of area.

OpenStreetMap data is very primitive information. There are Nodes which are a lat/lon point with some associated tags. There are relations, actually two relations. The Way which describes a physical link between Nodes; it has a direction (based on stored order) and tags. Finally the Relations which describe the more complex relationships for ways and nodes.

Existing editors are all about making it easy to manipulate these primitives easy. JOSM has plugins to help construct multi-polygons, turn restrictions, and many other things. Each and every one is assistance to changing the primitives.

Part 2 I will go into the details on what direction I'm going with this.