[OSM-dev] Announcing: Simple Map Editor (GSoC 2010)

Michael Daines michael at mdaines.com
Fri Aug 20 04:33:47 BST 2010


> Ah, something we need to clear up here: there's a difference between
> "simple editor/application" and "simple UI". There is no such thing as
> a simple editor. It's just not possible to be both "simple" and
> "working". The OSM data model is complex and sophisticated, and any
> attempts at a 'simple' editor will simply mess up other peoples work.
> 
> But even the simple "rename a pub" editor is more complex than most
> people realise. Naive implementations of a point-of-interest editor
> break down as soon as they realise that all POIs can also be
> represented by a closed way, and that these ways - both closed and
> unclosed - can be part of multipolygons. It's complicated. POI != node
> and Road != way.

When I first started working on the editor, I had generality in mind, and I decided that designing with a few simple use cases in mind was the best way to go. My thinking was that if these could be done reasonably well, they could be extended to include most of the node and way editing I might eventually want. Editing the names of roads was one of these simple cases. Another case was adding supplementary information to amenities.

Of course, anybody who looks at even these simple cases is bound to get lost clicking around the map feature documentation on the wiki. Part of my goal is to not be a tag editor, and in fact to never to use the words "node", "way", "tag", or "relation". I want to provide an interface that would seem more or less unsurprising to a beginner interested in editing the map. It works like this: you find something, you click on it, you see that you can change some things about it, and then you save.

But the map is very complicated, and you've got to have some idea of what you're doing when editing. I absolutely agree that this complexity can't simply be forgotten about. But let a simple editor have a few corners of the map! Here's what I mean:

At some point during development, Graham brought up the idea of custom editors. He suggested an editor geared toward wheelchair accessibility, and pointed me to an application that would display smoking and non-smoking establishments (related to a proposed smoking ban). When deciding where grab a bite to eat late one night, the possibility occurred to me of an editor which would parse the opening_hours tag and display restaurants which were open right then and allow me to fill in this information when it was missing.

While you can't say every way is a road, or every pub is represented by one node, I think there are lot of cases where this sort of thing actually is okay. (It would be more okay if the editor would be able to present ways as areas. Then a lot of parks and buildings would suddenly become editable.) Of course, it follows that there are situations where this kind of thing doesn't work, and my response to this is: the editor doesn't support that! Use Potlatch or JOSM, because they are more powerful.

The question is what to support. Without a lot of editorial work, by which I mean deciding how to translate the existing map data and editorial guidelines into some ideal editor configuration, I don't think my editor is fit for general editing quite yet, but I think that is a reasonable goal. It's just not really easy to pick what things to support. (You can be as descriptive or prescriptive as you want.)

Another way to apply the work I've done is by making it easier (for technical people, I guess) to create small custom editors that are good at doing a specific thing, like any of the situations I mentioned. This is possible already by forking the project and editing the configuration files. But if you could load your own configuration file into the editor somehow, then you could avoid forking the code and setting things up on your own server, etc.


-- Michael




More information about the dev mailing list