Reviving the area:highway Rendering Discussion: A Strategic Case for QA and Data Integrity


Wow that looks good!

2 Likes

I started mapping them as I was annoyed with 3-4 “separate” bridges being shown, instead of just the one actual bridge with multiple lanes & walkways :roll_eyes:

2 Likes

Mapping a wide pedestrian path is absolutely not the same as mapping a pedestrian area with area=yes. As I mentioned, it looks great on Cartio, but the effects on routing are catastrophic.

It’s not very noticeable for walk routing, but when other parts of the campus are for vehicular usage, mapping highway=service and area=yes confuses routers significantly as it creates 3 paths per road: Two on either side for the area, and one for an additional highway=service that is the actual path, not the just extent of it (as the area=yes way intended).

1 Like

I wasn’t saying that pedestrian areas should be mapped highway=pedestrian + area=yes, just that it is an established tagging, and so Carto has decided render it (but has dropped rendering of other highway + area combinations, except for highway=service).

In terms of the original issue, I don’t think there is much value in trying to get Carto to support area:highway, not least because support on the OSMF servers is limited (with good reason) to zoom level 19.

I don’t think that the zoom level being restricted is a good argument because the changes for wide pedestrian paths and service roads are visible at that zoom level. It’s not negligible like you seem to imply.

The difference between osm.org and https://layers.openstreetmap.fr/ as mentioned by @cowboyxup and confirmed by @CanopyFalls is night and day. That alone should justify the need for the rendering change. It is useful information, and it is visible at the mentioned zoom levels.

If you are opposed to this on the basis of technical challenges then I would understand, but you are describing this proposed change as insignificant, when that is plainly just not the case.

1 Like

Yes, the white filling is confusing for higher classified roads, but since this style a carto fork (GitHub - cquest/osmfr-cartocss: Une adaptation "FR" de la ré-implémentation du style Mapnik d'OpenStreetMap en CartoCSS), it can be adjusted.

2 Likes

To reiterate: Comparing the Royal Holloway University Campus on CoMaps (which renders area:highway for pedestrian and footpath highways) to Cartio:

Comparison

Feel free to make up your mind on which one looks better (the CoMaps data is slightly out of date, hence the minor differences).

Also note those pedestrian paths at the bottom right. A previous contributor marked them area=yes and highway=pedestrian, as well as sending another highway=pedestrian through the middle for good measure. It’s very obvious that they meant to use area:highway, but for whatever reason opted to use their method, which messes with routing in routers. Had area:highway always been rendered correctly on Cartio, there is a good chance that this mistake would have never been made.

Presumably this is a game that we can all play :smiley: - here’s my version :

I guess that you’re referring to this multipolygon and this way? In the second case I’d agree because it’s obviously the area filled by an essentially linear highway.

With the first, I’m not sure - there is no linear highway through here.

That multipolygon down south is something I am yet to clean up, well spotted. Before my changes, the rest of the linear ways I’ve mapped were all mapped with area=yes.

Also, your map looks great - it doesn’t render area for footpaths, but I can see the service road area rendered and it looks really good, and I wish that was on Cartio.

Nonetheless, is there any real reason left to oppose this? I believe we’ve proven that this is a genuinely helpful change on the map that improves it’s quality, so why do we not render it on Cartio?