About micromapping and accuracy vs. consistency

I’ve been thinking about this quite a lot and I think I’d like some community opinions.

About micromapping and my mapping style

Micromapping is very appealing to me and it’s the style I prefer practicing. Contributing to OSM is one of my main hobbies actually, right now. My current project is micromapping an entire neighbourhood to the highest degree of detail and accuracy that I can manage.

Generally, I’ve always operated on a principle of “the more detailed, accurate and comprehensive the data, the better”. After all, we can all agree that adding a missing business to the map, specifying the surface of a road or mapping individual parking spaces in a car park are objective improvements. Popular projects like StreetComplete likewise focus on the pursuit of maximum ‘completion’ (detail) in their messaging.

The potential issues

However, as of late I’ve been wondering about what happens to the edges of and the transitions to such micromapped areas.

If you take micromapping to its logical conclusion, eventually you’ll arrive at meticulously mapping all streets, roads, paths and junctions as area:highway, every sidewalk as a separate way, every small plaza as highway= with area=yes. You’ll map (the outline, not the private property in) every single backyard. You’ll stick to new and fancy standards like public_transport=platform instead of highway=bus_stop, education= instead of amenity=school and you’re practically the PR agent of the healthcare= key.

And… well, there’s going to be a severe mismatch between ‘your’ areas and the rest of the place. All your roads are suddenly 2D areas, all your sidewalks are separately traced, all your buildings are perfectly catalogued by type. Every tree is mapped where before there was only a lonely landuse=forest area. Perhaps you switched completely to highway=path instead of footway or cycleway for shared walk-and-cycle paths, because it’s semantically more accurate like that.

But what happens if a regular end user now accesses your data in some way? Suddenly, the map style changes for one neighbourhood. Forests look different, and suddenly backyards appear on the map and are green. Roadways, paths and sidewalks suddenly look and act differently.

Initially, my response would have been simple: “well, the better data always wins out, continuously improving the map is the whole point of contributing; and we shouldn’t map around deficiencies in the renderer or the router”. And that’s still correct, I think. An area:highway is objectively more detailed and accurate than a regular one-dimensional highway way. Manually mapped sidewalks provide much better information about the walkability of a location.

But what about the consistency with the rest of the area? Does it really have any value, and if so, when does it win out over accuracy, if ever? The wiki seems to occasionally value consistency, as it does defer to ‘local community practices’ in places.

If my entire local community maps plazas as a grid of imaginary one-dimensional footpaths, then I think I’d do well to replace it with a proper closed highway=pedestrian way with area=yes whenever I spot it, because the existing mapping contradicts the principle of mapping what’s actually on the ground. After the edit, it is going to be represented more accurately.

But then it’s the only plaza in the whole town to be different, unless or until someone decides to do the same to the other plazas throughout the city. Now it might appear in queries as the only plaza in the entire city. Perhaps map applications are going to display it strangely. Maybe it breaks routing with routers which cannot route through areas.

My conclusions

In the end, I think the best way forward is to simply keep pursuing the highest possible accuracy and to largely disregard consistency with historical local practices as a value.

Every improvement ever made has introduced inconsistency compared to non-improved mapping, but it doesn’t mean we should stop improving things.

And even if only a single neighbourhood is mapped with area:highway 2D highways, and the transition to the rest of the road network is jarring; it might simply be a stepping stone toward lifting the surrounding area up into that more detailed, better standard.

Most importantly, the only reason why consistency mismatches might become an issue in the first place is because apps and programs somehow mismanage or inconsistently process data. There’s no reason why a navigation app should give a user a bad experience when the road switches from a one-dimensional way to a 2D area. If I now stopped micromapping for that purpose and instead kept the previous style for consistency, I think that’d be an instance of Mapping for the Renderer or Mapping for the Router.

But I’d still like to hear others’ opinions on the topic, especially since ‘established practices of the local community’ are referenced often enough to make me wonder whether I’m stepping on a lot of people’s feet when I micromap my little neighbourhood area.

2 Likes

Do you keep the linear ways or do you remove them when you micro-map?

You called it “improved”, but if in the long term, you don’t maintain it, you degrade compared to the previous mapping where people could maintain the previous granularity.
How do you even maintain trees in a forest? You can’t even map each one.

If you have never heard about graph theory, it’s time to take a book or learn about it.
BTW, on a square, you can create virtual paths for instance. But for roads, you have then to split sidewalks and lanes for instance, add direction infromation (vehicles follow their lanes in general, it’s not a wild 2D surface).
Mapping means to create abstraction. You won’t map every single gravel on this gravel roads, would you?
As @Hungerburg mentioned, you have to keep the lower level of details.

BTW, Disponibilité du PCRS *vecteur* de Bordeaux Métropole - Sources de données - Forum OSM France is the kind of data that seem to be interesting to integrate. 1.7 GB just for a city. But you have then the equivalent of 1.7 GB (if you want all) to maintain.

As with OSM this is not the case. The more detailed your data get the more error prone your data gets. Suddenly people forget to tag sidewalks/cycleways with lit although the street itsself had it.

Crossings are impossible because of missing connections.

With more detail the complexity rises exponentially.

My issue with micromapping is that people are not mapping “semantically” anymore. Its all about looks and everything which gets rendered get abused horribly.

landuse, meant for semantically classifying large swaths of land is suddenly abused for sub m² mapping of individual trees, flowers and the like. And no - this makes Data less semantically correct, and less usable.

Flo

8 Likes

That just sounds like bad micromapping :slightly_smiling_face:

Going by the wiki, micromapping includes things like mapping building entrances, steps, benches, trash bins, etc. I hope we can all agree that sort of thing is useful.

The problems you raised are valid ones, but I don’t think they’re an indictment of micromapping as a whole.

3 Likes

Indeed, therefore the comments :wink:.

Well yes, I agree some of the OP’s examples are also bad. Just don’t want the baby to get thrown out with the bathwater, so to speak :grinning_face_with_smiling_eyes:

1 Like

User A microamps micromaps using background imagery X,
User B microamps macromaps micromaps using background imagery Y.
Eventually their areas grow till they meet up,
and there’s a several meters “rift zone” to deal with!
We’re talking as in tectonic plates, due to different offsets.
Bad day battling the spell checker today.

Stepping towards a consensus-aimed “mid-level” perspective (neither micro- nor macro-), most of us in OSM believe we know what a “decently-mapped-macro” mapped area is (data-wise especially, though certainly as rendered as a secondary, yet still important, consideration).

We’re discussing what the more-particulars of a “decently-mapped-micro” mapped are (ditto).

What I think many would agree to is that the interface /edge at / between these, while likely to be quite noticeable when rendered, wouldn’t be especially “jarring” (visually as rendered, or, again, data-wise as the more important consideration). That’s something to aim for, at least.

Seems obvious as I type this, but “not jarring at this edge” could be either a good discussion point or part of a partial or intermediate goal.

1 Like

as was already suggested by others, you should not “replace” linear highways with areas, in particular when it would affect routing (i.e. when there actually is a linear connection).

6 Likes

can you link affected area, maybe with photo how it looks on the ground? this can describe a wrong edit

you are adding area:highway in addition to highway= - not replacing the, right?

2 Likes

Do you keep the linear ways or do you remove them when you micro-map?

As I understand the wiki, I’m supposed to keep the traditional linear ways to denote the overall flow of the road, and map the area:highway as an addition, and that’s what I’d do.

I was concerned about data consumers such as map apps or navigation programs understanding the area:highway as a looping one-dimensional way rather than an area, causing phantom roads. Of course this shouldn’t affect mapping practices as per Don’t Map For The Router, but I nonetheless was wondering this.

2 Likes

I think you’re confusing two things I mentioned here.

Your hint is indeed correct when it comes to mapping the extents of a linear highway as an area, as per area:highway. You keep both the linear way denoting where road itself goes, and add the area as an addition to specify the exact extents of the surface of the road.

In the example you quoted however, I was talking about a plaza. Plazas and squares (highway=pedestrian and area=yes) should not contain imaginary footway grids in them just for routing purposes.

The only ways that should cross through such a plaza are ones that physically exist crossing the plaza, such as a service road.

This is also visible in the example image on the wiki:


The plaza does not contain additional footways where there are none. It’s one big highway=pedestrian with area=yes.

I mean, I’d hope people micromap based on on-foot surveying and GPS tracks and use aerial imagery as a crutch reference only. I can’t imagine mapping any level of detail with aerial imagery only.

I am a computational linguist, I build state machines for a living.

Not all landuse=forest areas are dense natural forests used for forestry, because some local communities refuse to use natural=wood and instead tag every green area with trees as a forest.

Look at this one for example, which contains a handful of trees easily countable by anyone who spends five minutes in the area:

Of course I’m not going around mapping individual trees in a large natural forest. That’d be ridiculous.

This is a solved issue. Roads that are mapped as 2D surfaces according to area:highway contain the traditional one-dimensional, linear ways which hold all the lane information, the road name and such. The 2D areas are additions.

On squares and plazas however, mapping what you call “virtual paths” is very much not a good idea. It’s mapping for the router, it’s mapping imaginary features that aren’t physically there. Truly nonlinear squares should stay areas only, and competent routers can freely route through the area. Only verifiable roads that happen to pass through an area should cross an area.

This is as per the documentation here:

If we used this as a heuristic, we should not map anything beyond roads and buildings at all. Of course detailed data may introduce errors, but adding any data may introduce errors. Since we’re a mapping project though, adding data is kind of the whole point.

I think a more useful heuristic would be whether we add useful data or not.

That’s true, and that’s why right now I’m generally against mapping sidewalks separately in areas that you reasonably can cross the road at any point, like low-speed residential zones. In higher-density areas, mapping separate highways makes sense, though.

If people don’t map semantically and instead map for looks, they directly disregard basic quality principles of OSM, regardless of whether they micromap or not. Any data, regardless of mapping style, is supposed to be verifiable and authentic.

Micromapping itself does not relate to any of these issues at all. Micromapping is essentially just a higher level of detail in the data you map.

Of course the data still has to be accurate and verifiable, and mapping for the router or mapping for the renderer are bad regardless of detail.

This is ironically something that micromappers constantly combat, actually… Micromapping requires constantly looking up keys and tags to most accurately describe tiny features. I’d posit that micromappers are less prone to these issues compared to others. If they misuse landuse tags for tiny hedges and flowerbeds, that’s a general quality issue, not a micromapping issue. Tags like man_made=planter exist for a reason.

Macromappers are the ones who skim some areal imagery and just slap landuse=forest onto it, even though it’s a green strip or a hedge or whatnot, like here:

Micromappers are usually the ones using detailed and granular tagging, because that’s the whole appeal of micromapping: being as accurate to and comprehensive about what’s on the ground as possible. This comes with its own host of issues, but overusing landuse isn’t it.

And seriously, individual flowers? I’d genuinely like to see an example of anyone mapping an individual flower, let alone as a landuse= element.

2 Likes

Well, this node isn’t far off - it looks tiny on the linked Mapillary picture :smiley:

In the mentioned way, it’s about 2 tree rows, possibly to do with a third. Not a forest in any case.

If people don’t map semantically and instead map for looks, they directly disregard basic quality principles of OSM, regardless of whether they micromap or not.

See above…

No, it’s about paths people follow usually (informal=yes, see Tag:highway=footway - OpenStreetMap Wiki). You don’t move in a square randomly (you can, you can play there too, but that’s not what I’m speaking about). “This is as per the documentation”, which documentation doesn’t mention that.

Yes, but everybody must anchor their edits to something, be it the house next door (which was originally anchored to the air pic), or raw coordinates (which alas are extremely hard to map with with e.g., iD. It’s not like you can plunk something down at a given X,Y, even if the Surveyor General gave you those coordinates personally.) Or OK, we all map from (wavy!) GPS traces.