Re: [OSM-dev] Announcing: Simple Map Editor (GSoC 2010)
Am 20.08.2010 05:45, schrieb Michael Daines: How do you see this working? Just opening a changeset at the beginning of the editing session and letting it close automatically? I'd do it that way. Peter ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Announcing: Simple Map Editor (GSoC 2010)
- I can only add predefined tags - I think there should be a more common way to add tags. The best way is to simplify adding relevant tags by using data mining (Which tags are often used together with the tags already defined?) to propose new tags instead of manually predefining tags! Or do you have implemented it already this way but the test data set lacks some data? Anyway, I (not a beginner) want to be able to add any tag I want. The idea is that as a beginner you wouldn't yet be sure what tags add anyway. (Or wouldn't even yet care how OSM uses tags or nodes, etc.) This is more of a design decision than a technical limitation. - I want to be able to zoom out to see the whole geometry. Right now the editor loads map data through the standard /map bbox query. Loading a lot of map data when zoomed out would be slow, (it is already slow on the production API) but perhaps in the future, XAPI could be used to only load the kinds of things the editor can actually do things with? - I agree with Sebastian Klein: Do not force the user to cancel or save, but save the whole as one changeset. How do you see this working? Just opening a changeset at the beginning of the editing session and letting it close automatically? Or would it be reflected in the interface? I want to avoid presenting the concept of the changeset and also make it clear that some action is taking place when editing. I don't want the user's edits to be silently transmitted to the servers without them realizing it. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Announcing: Simple Map Editor (GSoC 2010)
osmdoc.com gives 12092 uses for phone= and 891 uses for addr:phone= so I'd change what's in the wiki and use phone= and fax= and website=. For any Reasons email= is not as popular as addr:email=. This is the reason I have prioritized phone in the telephone field. However, I should mention that the form is smart enough to see other possibilities for the same tag, so if you edit something that uses contact:phone, the editor will modify the contact:phone tag instead of adding its own phone tag. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Announcing: Simple Map Editor (GSoC 2010)
Am 20.08.10 05:45, schrieb Michael Daines: - I can only add predefined tags - I think there should be a more common way to add tags. The best way is to simplify adding relevant tags by using data mining (Which tags are often used together with the tags already defined?) to propose new tags instead of manually predefining tags! Or do you have implemented it already this way but the test data set lacks some data? Anyway, I (not a beginner) want to be able to add any tag I want. The idea is that as a beginner you wouldn't yet be sure what tags add anyway. (Or wouldn't even yet care how OSM uses tags or nodes, etc.) This is more of a design decision than a technical limitation. Of course, it is about showing an inexperienced user what makes sense by using intelligent predefinitions based on algorithmical choice. Nobody needs to care about features or even tags and keys ;) - I want to be able to zoom out to see the whole geometry. Right now the editor loads map data through the standard /map bbox query. Loading a lot of map data when zoomed out would be slow, (it is already slow on the production API) but perhaps in the future, XAPI could be used to only load the kinds of things the editor can actually do things with? You only need to reload data when the user unselects a feature. Zooming out is just to get an overview. Anyway, this is just a detail. - I agree with Sebastian Klein: Do not force the user to cancel or save, but save the whole as one changeset. How do you see this working? Just opening a changeset at the beginning of the editing session and letting it close automatically? Or would it be reflected in the interface? You select a feature, it's getting highlighted, the tag box is opened, then you edit tags. As soon as you unselect the feature by selecting another one or clicking anywhere, your changes are saved on the client, somewhere appears a red SAVE button after your first edit. That's it. No need to explain changeset or anything to the user ;) I want to avoid presenting the concept of the changeset and also make it clear that some action is taking place when editing. I don't want the user's edits to be silently transmitted to the servers without them realizing it. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Announcing: Simple Map Editor (GSoC 2010)
It's awesome that it uses OAuth, I tip my hat at you for getting that working! I hope to see many people building on your work. Could you explain more what the ruby proxy layer does? Is it just handling the session stuff or does it do translations between OSM API and the javascript code? Sessions are handled by keeping the OAuth access token in the user's localStorage. (I believe this is incompatible with several versions of Internet Explorer, but it has an equivalent method I can implement later.) I don't know that this is the best solution, but I think it's the closest to what a desktop application might do when dealing with OAuth, and it allows me to not have to keep state in the proxy, so no database. The proxy layer is split into two parts: - A proxy for doing bbox queries on the map, which requires no authentication. I use the rack-streaming-proxy gem for this. - A proxy for OAuth and the API methods requiring authentication. This is in lib/osm_auth.rb. The /auth/request and /auth/access URLs handle getting request and access tokens, and the /proxy/* handlers use the OAuth gem to make requests to the API. I send the access token and secret from the JS part using special headers. I'll also put out a plea to any Ruby/OAuth experts that we're still looking for someone to tackle http://wiki.openstreetmap.org/wiki/OAuth/10a I believe there's also some newer version of OAuth which specifically takes into account browser applications (although the last time I checked, that stuff wasn't really standardized). Another thing that would be nice would be being able to tell the API I want to revoke tokens. Right now, if the user authorizes and deauthorizes several times, old tokens can pile up in their OAuth settings. I log out by simply clearing the token from localStorage. -- Michael ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Announcing: Simple Map Editor (GSoC 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 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Announcing: Simple Map Editor (GSoC 2010)
On Mon, Aug 16, 2010 at 11:46 AM, Mike N. nice...@att.net wrote: I'd like to announce my GSoC 2010 project which is nearing completion, a simplified editor for OSM aimed at beginner users. Looks great - I hope we can apply the concepts here to create simple editors to encourage new users to participate. 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. Especially when you start touching relations, which seeing as relations themselves involve nodes and ways that's pretty much any editor. I say this as someone who wrote the split way but preserve the order of route relations code in P2. 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. However, we can certainly do much, much better at making simple user-interfaces for these complex editors. In some cases we can hide the complexity - like making pub-as-area have an icon and be just as easily re-nameable as pub-as-point. But we should also split out the ideas of simple user-interface from hardly any features interface. An improvement I'd suggest straight away is to make road classifications a drop-down. But if we want to have editors with simple user interfaces (and I reckon we want that quite a lot) we need to realise that they will be built on top of complex, sophisticated applications. One minor tagging note: It uses the tag phone= for the phone number, but that is officially a rejected tag according to the Wiki. The recommended tag is contact:phone= . Oh dear god, the wiki. How exactly something that is widely used and supported can be called rejected is beyond me. Never mind that it's apparently been rejected by a self-appointed group in favour of something that hasn't even been approved! Cheers, Andy ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Announcing: Simple Map Editor (GSoC 2010)
On Sat, Aug 14, 2010 at 10:12 PM, Michael Daines mich...@mdaines.com wrote: - a proxy layer in Ruby, for communicating with the OSM API, - a collection of JavaScript classes and routines for connecting to the OSM API, working with map data, and authentication with OAuth, which can hopefully be used in other OpenLayers-based project that require map editing functionality, Hi Michael, It's awesome that it uses OAuth, I tip my hat at you for getting that working! I hope to see many people building on your work. Could you explain more what the ruby proxy layer does? Is it just handling the session stuff or does it do translations between OSM API and the javascript code? I'll also put out a plea to any Ruby/OAuth experts that we're still looking for someone to tackle http://wiki.openstreetmap.org/wiki/OAuth/10a Cheers, Andy ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Announcing: Simple Map Editor (GSoC 2010)
Michael Daines wrote: Hello OSM, I'd like to announce my GSoC 2010 project which is nearing completion, [...] Questions, comments, and bug reports are much appreciated. Also, I plan to update the wiki page with more detailed and current information soon. I believe the editor can be production-ready with a bit more testing and polish. Let me know what you think! Great, looks really promising! Let me comment on the user interface: * It would be good to cancel the current operation if you click on the map or another object. * If you click an object far right, it is hidden by the dialog, which is kind of strange. * A highlighting on mouse-over would be very fancy. * Allow to click POIs that are part of a way. Another thing I noticed: It creates a new changeset for every operation. It should remember the changeset and add subsequent requests to it. I recommend you have a look at the JOSM presets. They are quite comprehensive have been actively maintained for a long time. Sebastian ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Announcing: Simple Map Editor (GSoC 2010)
On Sat, Aug 14, 2010 at 23:12, Michael Daines mich...@mdaines.com wrote: Questions, comments, and bug reports are much appreciated. Also, I plan to update the wiki page with more detailed and current information soon. I believe the editor can be production-ready with a bit more testing and polish. Let me know what you think! I like it, thanks. like the smooth user interface. using http://github.com/mdaines/simple-map-editor/blob/master/app/forms/ could be adapted to users of different languages, right? a couple of feature requests: * add a permalink to a given area. * when authorizing the app, by coming back to the application, I get back to a whole world view, which is suboptimal. -- -S ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Announcing: Simple Map Editor (GSoC 2010)
2010/8/15 Simone Cortesi sim...@cortesi.com: * when authorizing the app, by coming back to the application, I get back to a whole world view, which is suboptimal. Strange. For me, after a short while in the whole world view, the app restored my previous zoom and everything and also had the new POI still set correctly. Cheers Colin ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Announcing: Simple Map Editor (GSoC 2010)
On Sun, 15 Aug 2010 05:12:06 +0800, Michael Daines mich...@mdaines.com wrote: http://simple-map-editor.heroku.com/ This got my attention because I've been pondering developing my own web-based editor. I have a Windows Mobile based smartphone (Motorola MC75) that would be a brilliant survey tool if only it could be used to edit the map. I've been investigating my options of which a pure web editor is one possibility. Sadly, no map tiles show up at all in Opera Mobile 10 at the above URL. (www.openstreetmap.org loads and is *almost* usable.) I haven't done much testing in Internet Explorer. Please use Firefox, Chrome, or Safari for now. (I will deal with browser compatibility issues soon.) When considering browser compatibility, you might also consider mobile browsers? Which, realistically, is Safari (Webkit) and Opera Mobile. a simplified editor for OSM aimed at beginner users Beginner users and mobile users are probably very similar in terms of what they're trying to do. Probably just adding POIs and street names. Maybe mobile considerations could be for GSoC 2011? -- Andrew Gregory mailto:and...@scss.com.au http://www.scss.com.au/family/andrew/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Announcing: Simple Map Editor (GSoC 2010)
On Sun, Aug 15, 2010 at 8:10 AM, Andrew Gregory and...@scss.com.au wrote: On Sun, 15 Aug 2010 05:12:06 +0800, Michael Daines mich...@mdaines.com wrote: http://simple-map-editor.heroku.com/ [ ... ] When considering browser compatibility, you might also consider mobile browsers? Which, realistically, is Safari (Webkit) and Opera Mobile. [ ... ] Maybe mobile considerations could be for GSoC 2011? Dear Michael, Thank you for getting me on the right track in our off-line conversation. I think this project shows a lot of potential and I'm very pleased to see what you have done with it. Can you share with us, your plans regarding this project at the completion of GSoC 2010? I hope that you will find a wonderful community of co-developers and happy users. Perhaps your initial browser compatibility work will make it easier for Gregory to provide further compatibility for his mobile browser of choice? Best regards, Richard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Announcing: Simple Map Editor (GSoC 2010)
Am 15.08.2010 11:16, schrieb Sebastian Klein: Michael Daines wrote: I recommend you have a look at the JOSM presets. They are quite comprehensive have been actively maintained for a long time. You could fetch them via web from [1] and to some filtering on it (eg. only item /-Tags with type=node) Peter [1] http://josm.openstreetmap.de/svn/trunk/data/defaultpresets.xml ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Announcing: Simple Map Editor (GSoC 2010)
Hello OSM, I'd like to announce my GSoC 2010 project which is nearing completion, a simplified editor for OSM aimed at beginner users. It's also meant to be generally useful for quick edits to the map, and to be customizable to allow creation of site-specific editors. Some of the use cases I considered were adding names to roads and entering contact information for businesses and amenities, and developing a custom editor for keeping track of restaurants that are open late. The project consists of: - a proxy layer in Ruby, for communicating with the OSM API, - a collection of JavaScript classes and routines for connecting to the OSM API, working with map data, and authentication with OAuth, which can hopefully be used in other OpenLayers-based project that require map editing functionality, - an HTML/JavaScript application capable of modifying tags or nodes and ways and creating new nodes, using the above components. The application is available to try out here: http://simple-map-editor.heroku.com/ Please note: - I haven't done much testing in Internet Explorer. Please use Firefox, Chrome, or Safari for now. (I will deal with browser compatibility issues soon.) - Right now, the app connects to the development API, so it may look like there is no data anywhere. You can add nodes yourself, or search for South Bank, London, where I happened to find some test data at the beginning of the project. - Also, you'll need an account on the dev app server. If you don't have one, you'll be prompted to create one when the app tries to authorize. - The app only knows about a few kinds of map features. More will be added. Source is available here: http://github.com/mdaines/simple-map-editor Questions, comments, and bug reports are much appreciated. Also, I plan to update the wiki page with more detailed and current information soon. I believe the editor can be production-ready with a bit more testing and polish. Let me know what you think! Thanks, -- Michael Daines ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
