treee111
one vs. two sets of tags in constants.py for filtering out OSM tags
this issue is about discussing the two sets of constants here: https://github.com/treee111/wahooMapsCreator/blob/df809469844b973a3acbe23d7176b8209b099932/common_python/constants.py#L203-L226
Discussion of #108
Can you (or anybody else) remember why we need two distinct sets resulting in two filtered files which are then merged with land and sea on the tile processing/generation?
Was it because of CLI argument length limitations on some platform?
Originally posted by @mweirauch in https://github.com/treee111/wahooMapsCreator/pull/108#discussion_r855530532
I looked it up.
We introduced the _NAMES constants and corresponding osmium / osmfilter processing in #46. There are some sentenced about filtering out names of highways etc. with these additions.
I think lately there was a discussion about the need of these two sets in Telegram with no real outcome. In my opinion there might not be a technical need for two sets.
I'll try if my unittests check if there is a knowingly error. If yes, I could refactor that part in another PR.
Originally posted by @treee111 in https://github.com/treee111/wahooMapsCreator/pull/108#discussion_r855559630
Ah, thanks. I think I have not fully understood the filtering behaviour of the tools entirely.
At least on the non-Windows side this has no effect as the second osmium tags-filter operation does not explicitely list a name= filter expression like the second osmfilter operation does on the Windows side.
But adding it, the filtered germany map for names blows up from 263MB to 1109MB.
No matter what, names are present when checking with osmium tags-count or a custom vmt-elemnt.xml theme displaying highway names. So I dunno if the two tag-sets are really needed.
Perhaps we can take this discussion to a new issue later on.
Originally posted by @mweirauch in https://github.com/treee111/wahooMapsCreator/pull/108#discussion_r855598786
Just as a heads up ... I just did a little testing. Using osmfilter to only keep tag historic, making sure it's rendered by osmiums mapwriter plugin and the name tag of the historic node I am looking at is displayed just fine. So I dunno if this is just osmfilter magic with that special name handling, on the osmium side one wouldn't need two sets of tags. (I might still be completely missing something here.)
Originally posted by @mweirauch in https://github.com/treee111/wahooMapsCreator/pull/108#discussion_r855641673
Hi @mweirauch, to be honest I also not fully understand what is going on there with the filtering :-D I will also test that further. If I fully comment out the differen processings with the names-tags parts on windows the resulting file is different.
Hi B,
Not sure how "hot" this item still is but I am the one who introduced the name filter. As you know I can't say anything about linux/mac (osmium) but I can tell you the exact background on the windows version.
The intend was to keep the final map size down to around Wahoo map file sizes without using the map-writer simplification-factor like Wahoo does. If you look at the original maps with cruiser you will see the simplification leads to none touching roads, octagon shaped (small)roundabouts and even paths not being shown in my area.
So the first filter (on windows) keeps just the mentioned key:value pairs stripping names but also things like "lit", "maxspeed" etc. In short everything not used by the devices. If you check you will see there are no other keys in the filtered file other than the specified ones. So no more street names for roads. But if you look at the Wahoo maps with the corresponding render theme you will see that place names and the names of some other stuff is shown. And I wanted to mimic the Wahoo appearance as good as I could in that respect.
Enter the name filter... It filters out (or actually filters them in) all items of which to keep the name key:value. So just for place's, area's and natural items. After this you have of course merge the two back together to get a complete map. I could not find a way to achieve this in one filter action with osmfilter. Again on windows. It has been a long time ago but removing all not needed name tags decreased the map file size by 30-50% if I remember correctly.
Last weekend I saw that the natural key is in both filters I think it can be removed from the first filter because what the first filter is trying to omit is being introduced back in by the second filter. Changing the second natural filter to match the first one is also an option but because of the new color units it might have added value to leave them all in.
Hope this clarifies it a little
Hi @Ebe66, late reply but I have read your comment and agreed on it a long time ago. As I understand it right there are two sets of tags because they are used in different stages of the process to mimic wahoo style and get the filesize down. Putting them both into a set does not give that concreteness.
I leave the branch minimize-tags-sets there for reference but will close this issue.
In addition to the above mentioned the effort of implementing this and comparing the results is a lot of effort. The benefit (if there can be any) will not be worth the effort