This is a short write up of a small amount of thinking and investigation of potential ways Moabi could extend and contribute to tagging tools in OSM.

Tags are all too human

Tags are the magic tools that allow OSM to happen. There’s no systematic restriction to how features are tagged. Rather it’s based on experience, convention, conversation, invention. There’s no universal representation of the world, and tags permit that. It’s messy, not always rational, sometimes absurd like horse=yes, but also mapping social facilities in refugee camps. Using the common ones becomes an exercise in crawling through the wiki. Inventing new tags is a whole other adventure.

And so is software

Though, we make it easy on ourselves, and make tools to work a little bit with tags. There are presets for editors, style sheets for rendering, analysis tools.

How are tags read and managed by software? It’s still an (impressive) grab bag.

Editors

For iD, presets are defined as json files. Each presets specifies a tag, and other tags to fill out for that feature (“fields”), as well as synonyms for search and a logo. It’s a clean representation, focusing on the “data structure”, and the collection of features is managed through github. Afaik, there haven’t been many attempts yet to create custom sets of features. The would require compiling and hosting your own version of iD, there’s no way to do it directly in the website.

JOSM presets have been around a while. It’s an XML format that defines both tags and fields for features, and sets of features in a hierarchical menu, as well as labels and layout of dialogues. There’s dozens of preset files out there, HOT maintains a set for the Humanitarian Data Model, Map Kibera has created them, tons more.

Forever, it’s been a pain to create these JOSM presets. Hand writing fragile XML is not so fun. The http://visualtags.hotosm.org/ is a tool to create these presets. Here’s the code in github. Definitely a step up from hand crafted XML. Though still a little challenging working through the interface.

Rendering

Visualizing, there’s the classic tool chain of osm2pgsql and mapnik and now carto for transforming tags into cartography. Other tools, including editors like JOSM, use the similar but different to carto MapCSS.

And..

There are some QA tools which monitor tags, to look at common issues in how tags are assigned, how they are used in combination with each other, etc. There’s Validation tool built into JOSM. Keepright has a set of tag related tests. But there’s not really a framework out there which allows for general application of quality checks on tags.

And of course, there’s the mighty taginfo, which builds up global statistics on tag use, builds lists of combinations and geographic spread, and provides APIs for linking into other places tags are handled, like the wiki and editors, and links to other useful tools for querying on tags like Overpass Turbo. TagInfo is a sinatra app that others have set up, to focus on particular geographic places.

And what about Moabi?

Moabi wants to provide a bit more structure around tags. A group in Moabi (based off the OSM groups sketch perhaps), or a user, want to create a Feature within Maobi. That Feature is then made a searchable option in the editor. When a user creates or modifies a Feature in Moabi, it will be validated against that definition, and the results shown on the “browse” page. Further, there may be permission levels set on who can CRUD a Feature, or even at the level of specific Fields within a Feature. As well the definition of a Feature might have its own access rules.

Essentially, define, validate, visualize and restrict tags.

Pretty different then OSM right? Is and where is the overlap, and how do we best diverge?

And where do we do this again?

Honestly, I’ve always thought a central place to manage tags would be really useful. Well not to definitively enforce tags. But a place more functionally tuned to the problem then the wiki, that could provide some of the process of tag approval (even if tag approval has no functional meaning!), and then semi-automatically produce and integrate with the editors and rendering tools. TagInfo seemed like not a bad place to at least acquire some of these features … again without changing the fundamentally free flowing nature of tags. Just make it easier for us to track what’s going on.

Representation

Though “tags” are different from “features”. One nice thing about the iD representation is that it introduces this concept. JOSM presets has this as well, though it includes groups of features, whole menus of features, along with layout and labels. iD has json just define that single feature, which is built up of references to reusable fields.

Editing

Somehow, I prefer the iD representation, cleaner to build off. But then, does it need to be represented in a file? Where would the creation of features take place? It could take place in an external application, like the Visual Tag Chooser, or TagInfo, or something else. It would then require some secondary transformation and distribution steps to make its way into the OSM applictions, to be used in editing, validation, and rendering.

The other option would be a MVC of a Feature directly in OSM, taking advantage of any group or user permissions developed there, etc. We’d still have some transformational steps to bring those options into iD (by producing those json files, or building in a step in iD to get options from the DB), as well as to produce custom tiles more easily. Could possibly even make use of some of the interface components of iD itself to manage the editing here.

Validation

Validation during editing could be accomplished by iD providing some feedback during Save based off the Feature representations it has loaded. If that was structured properly, that JS validation could be isolated and reused as a part of the browse page. In this model, as usual, feature components are not enforced, but are made more visible in more places.

Restriction

If Features, or even particular Tags within a Feature, have some access restriction, that would need to be included in the Model and/or representation. Perhaps Groups are a natural way to strucure these permissions, or even Roles within a Group, or a Platform as whole. For Moabi, might even need to apply restrictions on the geometry of an object, only allowing it updated through particular import accounts, and just allow editing on other particular fields.

There’s two issues. This kind of access restrictions can be applied sometime during CRUD, and if a problem is detected, simply reject the entire Changeset, similarly to how editing out of data OSM objects throws a “conflict”. The other is, how can Features be identified as Features, and not just a collection of tags. For that, we might use some kind of “hidden” tag, as JimmyRocks suggests in the comments, which specifies the Feature, and can link to restrictions defined elsewhere. This idea could also be expanded to manage “approval” of contributions, so that within a Group, some members can contribute, others can certify.

So where to start? I reckon, we start with what’s more potentially generally useful, like tag definition and validation, and then move on to the more restrictive non-OSM options, when they’re really more clearly needed. But might also make sense to start with the least OSM like features, to really make sure that this whole direction of using OSM for non-OSM data makes sense.