The amount of segments used to represent a curved feature is based on assumptions. For example, an editor may interpret a mapper’s input by merging points that are too close together. Many aspects of the editing process depend on the drawing of curves, and many parameters are assumed by an editor.

A drag is a gesture well suited to mapping curves. Instead of lifting from a trackpad - an event which can throw the mapper’s precision off - the mapper drags along the feature’s centerline. Such a mode provides more consistent levels of mapping detail, a speedup in which a mapper can trace features, and a more natural feel to mapping. However, it requires more assumptions by the editor used.

In order to draw a line, one may drag from a way. The same gesture may move the map using merely a capacitive touch. I wonder what the current state of dragging is in all of the editors. Does a feature lack curves because it is closer to an urban grid or because it is tedious and/or arbitrary to map.

… See full entry

Today I stumbled upon wiki.camerabits.com for referencing metadata tagging. It was easy to find Wikimedia metadata Labels (which are like OSM Tags). Here is what I am thinking about mapping using exiftool, a command-line tool for displaying, adding and modifying media file metadata Labels:

• Source (same as Tag source)
• Description (same as Tag description)
• Web URL (same as Tag contact:url)
• Identifier (same as Tag wikidata)

Here are some other Labels that I’ve found to be useful:

• Persons Shown (semicolon separated list value)
• Persons Shown with Details (semicolon separated list of wikidata values)

Here are some static Labels that I would apply to all the public artwork for OSM:

• Copyright Info URL=https://creativecommons.org/publicdomain/zero/1.0
• Copyright=Public Domain
• Copyright Status=Public Domain
• Copyright Notice=Public Domain
• Rights Usage Terms=No Copyright

I would add custom Label=value pairs to the exiftool configuration file (which I am learning) for compiled media formats (i.e. PDF, PNG, JPEG, etc) originally from source (i.e. TeX, ODF, HTML, OpenXML, Markdown, Wikitext (and referencing wikidata instead of URLs/URIs)). These new metadata Labels would encode information about how to organise the source files, maybe even for fonts or images (if necessary):

• Src Format=tex (the file extension format for the source code)
• Src List=main (semicolon separated list of files in the src directory without extension)
• Src main=\documentclass{article} \usepackage[paperwidth=50cm, paperheight...

… See full entry

I recently discovered the mapbox feedback page and saw that they require you to classify the nature of your feedback. One click places the feedback on the map, and another click adds an instruction with your comment: * add a place (create a new feature with a list of tags) * fix a location (overwrite a feature with a list of tags) * rename a place (overwrite a feature with a name value) * fix satellite map (add a comment for satellite mappers) * remove a place (delete one feature with name value) * it’s something else (add a comment to OSM or something)

If users categorize their comments on OSM by type of instruction, AI could more easily interpret a comment string and learn to apply fixes by correlating human edits with comments.

I just learned about cesium.com/ion. It is a website that allows one to create ‘Assets,’ or sets of 3d-tiles, and host them for a cesiumjs.org instance such as webglearth.com ( 3d Leaflet ) . One can choose to upload (3d aerial photogrammetry)[https://cesium.com/docs/tutorials/uploading/] that gets carved into vector 3d tiles that are hosted as an Asset through Cesium. Each tile is one WebGL draw call.

Somebody might want to grow these 3d-tiles from the ground up artificially if he can’t fly from the skies. An Asset producer may regularly update from OSM in order to parse the tags for elevation, vegetation, buildings, etc in order to grow the tiles based on tags.

Some fun with Assets: let’s say you had 3 ‘visibility layers’ to choose from, those being buildings, vegetation, and terrain. To maximize efficiency, you should host X Assets if you have Y visibility options: X := Σ for n=1..Y, Y choose n. Basically, one Asset for every possible selection.

I just discovered iD-indoor, a friendly JS editor for mapping the Interior. It’s been in development for a few years now. OpenLevelUp is a corresponding renderer that renders vector building objects on top of carto. The idea is that, in both the editor and the viewer, features are filtered by level tags. This and similar editors/viewers can map features that share a boundary with a wall such as doors, rooms, corridors, and unwalled areas.

There are multiple ways that OSM could render a building differently. We can remove the roof, exposing the top level at the highest zoom layer. We can use the scroll wheel to cycle through the layers or we can blur relevant features from all layers. Take a look at this interactive campus map. It basically does the same thing as OpenLevelUp. It shows what can be done, as with Zillow, Google, and other GIS organizations.

Maybe iD-indoor should be considered an editor option here on OSM? Edit > Edit with iD-indoor (in-browser editor) or be merged with upstream iD. Advanced features can be made available to users by enabling interior-only and exterior-only editing options.

I just discovered webglearth.com, which is similar to osmgo.org. Both 3D renderers are open source web applications that have been in development for many years. These renderers can help us understand data in new ways. Each differs by what is rendered and by navigation style.

In WebGL Earth, 3D terrain is visible on the globe after zooming in. A click and drag moves the camera along the ground. Along with two modifier keys, the Alt key rotates the camera from a fixed position to allow looking around, and the Ctrl/Shift key rotates the visible surface about a fixed distance to allow orbiting.

In OSM Go, every building, tree, fence, utility pole, hedge, etc. is rendered as 3D. Selecting an object will display info and tags for that feature. Moving along the ground is possible with arrow keys. Holding shift allows looking around. Additionally, PgUp/ PgDn moves the camera up/down.

Neither project overlaps with the other. WebGL Earth considers a holistic reality by animating the earth. It has the potential to provide APIs for showing interplanetary trajectories. Meanwhile, OSM Go renders every urban cartographic feature, including underground ones. Its interactivity feels like the precursor to a Sims-like garden and floor plan modeler.

Recently, I saw a diary post about Microsoft releasing US building footprints, and I wondered how they could be used to add buildings to OSM in my favorite editor. I quickly found out that large files won’t load in iD. I searched for a tool that could make the files smaller and usable and found one called geojsplit.

I took it upon myself to examine the code of that project, to learn a bit of JavaScript, and to form it into a tool more suited to my needs. Large database files won’t load in iD, but they can be made smaller in size by omitting features outside the viewing window of the editor. As a result, I can now see the building traces in my favorite editor. :)

… See full entry

iD, JOSM, demo.f4map.com, osmbuildings.org - I’m calling out a few use cases for OSM today because I’d like to point out the difference in the quality of OSM data rendering.

Of course, OSM is more than just data: it’s a community! But it is also software. And that community must respond quickly to the demand for better quality maps (i.e. 3d, textured, or even animated). Every user uses OSM map data for different use cases.

iD is a great tool for mappers and is easily accessible through the web browser unlike JOSM, which also provides many other features (probably). Potlatch is a flash-based tool like iD that also allows dragging edges of nodes and viewing uploaded GPS traces. But neither tool will render the buildings or other topology.

This is where osmbuildings.org and especially demo.f4map.com become necessary tools to verify the 3D appearance of vector data when mapping. These tools possess the ability to modify our vector world from a perspective street view and bird’s eye view rather than solely from orthogonally projected satellite imagery.

Yet it is possible to adapt OSM to any structure on, in, or around earth in one continuum of data. It is possible to create orbital relations to other planets, each with its own spherical geographical coordinates to vector data. But the demand for OSM data awaits a community generous and flexible enough to provide the software that allows rendering and mapping it.