Copy iD's theme

[verhovsky]

I like iD editor's theme and it would be nice if the OSM editors I use had a consistent theme so I didn't have to learn more than one.

[bryceco]

If you're referring to the color palette used for roads, etc. then these are defined in RenderInfo.json. Feel free to update and submit a PR. Some of the other styling, like tunnels/bridges is done in code, but I'm not against changing it. Note that we don't use dashed lines anywhere because of performance impact.

[bryceco]

I'm not totally happy with the result of this. I was out mapping a couple days ago and certain lines are very difficult to see:

• trying to see the gray line for a parking lot on top of aerial imagery containing a gray asphalt parking lot is super difficult.
• power lines are also very difficult to see

Part of the problem is that these objects don't have casings. In iD the parking lot has the gray gradient next to it that makes it more obvious. Also the power-line line is thicker than what we show.

[verhovsky]

By grey gradient you mean that it's not a complete filled in grey, that the fill stops after 60px?

I couldn't figure out how to achieve that effect.

[bryceco]

Yes. I don't think it's possible without doing a bunch of math on the geometry.

[bryceco]

59876c7f0a013ec3255ef13e59a8375973c131bf

[verhovsky]

you could also try adding a faint shadow instead.

[bryceco]

I considered that, but I figured the performance impact for a shadow would be higher, and not much better appearance. But maybe I'm wrong.

[tordans]

I am also testing the new theme and have a couple of places that are not yet ideal in Berlin. I will try to document them more properly, but a quick list is…

• some outlines lines are white, some are black and I did not figure out yet when/why. I think it might have to do with the implicit "what is an area" concept that iD has; for example area:highway is an area in iD
• building passages of footways and service ways have a tunnel-like style in iD, which I am missing
• building:part are super tricky in iD and in the new theme even more so. They have a white line and make some buildings white-lined now
• This is a good area to check https://www.openstreetmap.org/#map=17/52.47919/13.43875 because it has a lot of detailed objects and taggings

And I agree, the casings style from iD is one of the biggest missing factors. But maybe we can also introduce a gesture that toggels the wireframe vs. fill style so it becomes easer to see the data, then see the source data and back. Are there any gestures that are not part of the iOS gesture level that could be used, like swiping in from the top right corner into the screen?

[bryceco]

@tordans The line styles and casings are translated from the iD source via a script, so in general they should be identical. If you can name specific way IDs that are rendered wrong it would be super helpful so we can see where things are going wrong. It's true that we're ignoring the whole concept of area at the level where colors are chosen, so that could be part of it.

I personally think the gigantic casings in iD are pretty ugly so I'm happy to leave them behind, though I see the advantage of not filling areas.

[tordans]

If you can name specific way IDs that are rendered wrong it would be super helpful so we can see where things are going wrong.

Barriers

https://www.openstreetmap.org/way/549291669

Barrier Curb

https://www.openstreetmap.org/way/1267121761

Areas

• Area highway https://www.openstreetmap.org/way/1184051602, same screenshots as barrier curb
• Area razed building https://www.openstreetmap.org/way/334062948
  • 

Footway + Footway Building Passage

• Footway https://www.openstreetmap.org/way/585098106
• Building passage https://www.openstreetmap.org/way/585098107

building:part

Example https://www.openstreetmap.org/way/560517989

All kind of playground line/way

https://www.openstreetmap.org/way/311072326 https://www.openstreetmap.org/way/60443941

building with black outline

https://www.openstreetmap.org/way/908199103

Missing icon in area

Not sure if this is important, but it is helpfull… https://www.openstreetmap.org/way/930016301

Embarkment

https://www.openstreetmap.org/way/1156140193

Parking

https://www.openstreetmap.org/way/888505080 Lines are softer(?)

Look of path like ways

The dashed lines in iD for Footway, Sidewalk, all the Crossing styles look noticable different in iD. They are thicker and the dash is different. I think it is harder now than before to distinguish a bike path from a sidewalk

This area has a few different stiles in one place https://www.openstreetmap.org/way/1000299492

---

Added 2024-05-06

retaining wall

Example

[bryceco]

Wow, very nice! This is your department Boris @verhovsky ! 😅

[verhovsky]

Amazing comment, thank you. I'll look into this on Saturday probably, I don't have my laptop with me right now.

[bryceco]

FYI over in Rapid there is a work in progress revamping how styles are done. It may or may not be easier to use that as a basis for the translation:

https://github.com/facebook/Rapid/pull/1384

[tordans]

FYI: The way the styles are set up in Rapid is a complete refactor of the iD setup (same styles, different software). That happened a whole back when the new Pixi based map was build. The current PRs (like the color blind PR you linked) build on top of this new foundation.

[bryceco]

Good to know! I didn't look into it deeply, I just saw that it was moving more toward a JSON representation.

[verhovsky]

https://github.com/bryceco/GoMap/blob/cd7664ee2bc7008d6c8e3c421c658cf73f03645a/src/Shared/EditorLayer/iD/Theme.swift#L34

is wrong. barrier is not a primary tag, things can be styled in the CSS without being a primary or having a primary. If you want to apply a custom style to things with certain tags, filtering those tags out should happen before .match() and .match() should always return a value.

[bryceco]

The specific situation I'm trying to handle is when a node doesn't match any feature, but still contains an address tag like "addr:housenumber"="155". This is frequent when importing address information from government sources. In that situation we return nil and detect that it's an address separately, and can style it appropriately.

If it matches a feature we want to style it like the feature, but if it matches nothing but looks like an address then style it like an address.

I guess another way to handle this is to expose the default style as a property, and if the RenderInfo returned == the default style then do the address check.

Feel free to delete that line and I'll clean up the address check later.

[bryceco]

f6fe5e961fb2b3a096e62a3936cf20a552cee965 removes that offending line and cleans up some related RenderInfo stuff that isn't needed now that every object gets its own non-shared copy of a RenderInfo.

[verhovsky]

barrier curbs (line formed out of grey circles) are still un-styled.

Also there are ways that should have arrows pointing out of the line, for example for cliffs "the direction of the way should be so that the top of the cliff is on the left side of the way direction and the bottom on the right side" and when you draw one in iD it draws arrows showing the direction of the cliff using this convention instead of drawing arrows in the direction of the way. Example: