The following post is best viewed at osmly.com full text is posted below for posterity.

---

OSMLY is a simple browser based importer for OpenStreetMap. It makes importing easy by presenting each feature one at a time, allowing users to manually review the item, make any needed adjustments to positions or tags, and upload directly to OSM. It also allows for reporting problems that other users can look over and a quality assurance mode where administrative users can confirm everything that has been uploaded. The aim is to make simple imports easier, more cooperative, and less error prone.

Try the demo: http://osmly.com/la-parks.html

OSMLY was born out of a frustration with the way imports are organized. I was preparing some imports for Los Angeles County, reading up on past imports and organized things according to how I see they are being done today (wiki, spreadsheets, many .osm files, JOSM). I wasn’t into it. The organization and tools involved seems too complicated and clunky for getting more than a small number of people involved.

Even with very simple data we would have to deal with many .osm files each containing many features themselves, a central spreadsheet for tracking who is doing what and the status of each group of items, and everyone would have to use JOSM. Then editing involves managing multiple layers in JOSM, downloading the area around each feature, looking around and resolving any conflicts, uploading in a small batch, and making sure to tag changesets correctly. Ideally, someone would then go back, search for the changesets and confirm everything was done correctly.

That’s too complicated for my liking and the pool of users who know how to do all this without making mistakes is too small. On the other hand, most of that complexity is necessary for organizing the people involved and maintaining some quality to the data going into OSM. I want a simpler and more automated way of handling the most manual and repetitive parts for really basic imports. I just want a simple way for someone with OSM experience and knowledge but not necessarily a GIS data or programming background to help out with basic tasks and share their knowledge to get more data on the map.

I built OSMLY to reduce the complexity of doing simple imports with many people and many features. It’s just the essentials: editing geometry, fixing tags, displaying relevant nearby features from OSM, flagging problems and uploading to OSM. Features are served from a simple database to keep track of everything/everyone and different actions are allowed based on an feature’s status. Once an item is submitted it’s available for Quality Assurance where other users can confirm everything was done correctly and flagged results can get attention from more experienced users in JOSM.

Technically, OSMLY takes in GeoJSON data and makes sure geometry is valid, simplifies, flags obviously difficult items, adds bounds for each item, and converts everything to a sqlite database ready to be served up to the world. A simple server takes care of routing requests from the browser to database queries and returning results. Once the user has received a new feature the surrounding area is download from an OSM server and those results are filtered for relevant geometry. Then it’s all displayed on the map. From there it gets a bit more complex depending on the user’s actions.

Some key features:

• Context - nearby relevant features that may conflict are shown alongside the item being edited along with complete tags. Context filtering can be set using regular OSM tags.
• Quality Assurance - administrative users, specified in the settings, can review everything that has been submitted and confirm each item has been done correctly
• Edit in JSOM - every item can be remotely opened and completed in JOSM if you prefer.
• Tag Manipulation - depending on your data source, you might not have to do any tag manipulation before OSMLY. Tag keys can be renamed, added, and removed.
• User Whitelist - specify exactly which users are allowed on an import or allow everyone (default)

Limitations: Currently OSMLY only works with polygons. Eventually, time allowing, I’d like to expand to other GeoJSON feature types (points and linestrings). OSMLY is only ment for simple imports so there aren’t plans for implementing multipolygons or anything else too complex. Some of this is technical but mostly it comes down to ease of use. Right now if a complex item is found OSMLY pushes the user to edit in JOSM.

---

OSMLY has been working great on the OSM development server for the past month. You can see my test edits here: http://api06.dev.openstreetmap.org/user/namdil-testing/edits

Source code @ https://github.com/aaronlidman/osmly

Technical bugs @ https://github.com/aaronlidman/osmly/issues

I’d love to hear your thoughts/concerns/questions. Just to make it clear, this isn’t live but currently works on the OSM dev server and I’d like to flush out a discussion here with the eventual goal of doing real imports. I have a couple imports with ready proposals I’d like to complete with OSMLY but only after I work through concerns you may have here. Thanks for your time.

---

There is an ongoing discussion on the OSM mailing-lists, if you would like to join in. https://lists.openstreetmap.org/pipermail/talk-us/2013-September/011796.html

When using OpenStreetMap data there’s a frustrating divide in the representation of a place. Something like a supermarket, a school, or a park. It can be as simple as querying [leisure=park] from an API but what are you going to get back? Probably a way (polygon) or a node (point) and depending on which one it is you have to do things a bit differently to get where you want. You can specify to only return nodes but you’re going to miss things, it’s going to be incomplete because some of them have been mapped as ways, some as nodes. Because of this mixed bag it can be frustrating to try and do even basic things with the data. I just want points of interest.

For those who really know what they’re doing the solution can be to load an extract into PostGIS and do a carefully crafted query to get exactly what they want. This isn’t easy for most users or me; PostGIS isn’t easy to setup, crafting that query takes previous knowledge of the schema and PostGIS functions, importing that data into the database will be slow and overly complete, and then can you start querying. I just want some GeoJSON.

The solution is pretty simple. Take the existing nodes, pass them through and convert the structure into the desired output. For GeoJSON this means creating a new feature, putting the coordinates in the right place, and changing the tags to properties. That’s it.

For ways it gets a little more involved because they aren’t self contained, the coordinates are kept elsewhere in the file. So we have to take the tags and references for each way, keep a list of all the necessary refs, and get all the coordinates we need to replace the refs. Then we can build the ways and use their centroid as the point. Along the way tag values like the names, phone numbers, or links can be normalized or filtered to only return a specified set of items.

I made openstreetPOIs to do this. You can specify the features you want based on their tags, and set a few options. The main goal is to take in any common OSM file, process it quickly, and do so without a database. There’s a growing list of features I want to add and some things this data makes easier to build. The long term goal is simple, clickable, POIs for an OSM based map with flexibility for customization, along with just having lots of useful POI data. Checkout the github repo for more.

I’ve been resolving OSM notes this past week and it’s been surprisingly engaging editing. I might try and sum up my pros/cons of the notes feature later but there was one particular problem that became a little project of its own that I want to explain a little more in depth here.

I came across notes by users didier2020 and jfire about parking lot duplicates in Washington DC. The problem was that some parking areas had multiple duplicate ways stacked on top of each other and shared the same nodes to define a single area. Because these areas were sharing the exact same features it’s pretty hard to spot the problem without specifically looking for it. Here’s what it looks like in JSOM:

When I first started on Didier’s note I spread out for a couple miles and kept finding the problem everywhere. Looking into the history of these ways it came back to an import of DC parking lots emacsen did in 2010. Here’s one of the changesets that make up the import: http://www.openstreetmap.org/browse/changeset/4118659. Now knowing that this affected all of DC I downloaded all the amenity=parking ways and checked it with JSOM’s validator. Here’s a recreation of what I saw (yellow is parking, red are duplicates):

JOSM’s validator can be a pretty great tool for solving lots of common problems but it can’t fix stuff like this on it’s own so I got started removing the duplicates from the top down. Once I got a reliable way of spotting them it was a simple process of keeping the cursor set to delete and clicking every way. Most only had one duplicate but many were stacked three or four high.

All in all it took about three hours, about 1,900 parking lots were deleted, the DC OSM file is a about 10mb smaller and there are now 6,166 parking lot ways in DC.