[Patch] More optional tags for routes and aerialways

[skyper]

This patch​ adds website, operator, fee and opening_hours to route relations and aerialway.

I introduced some chunks for aerialway:* and corrected the indent of all chunks.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2020-06-12 19:48:35 +0200 (Fri, 12 Jun 2020)
Revision:16610
Build-Date:2020-06-13 01:30:48
URL:https://josm.openstreetmap.de/svn/trunk

[skyper]

patch

[skyper]

version 2 including checkgroup for stop_position

[skyper]

The stop_position preset was missing checkgroups, so I add some in josm_route_aerial_update_v2.patch​.

[Klumbumbus]

Please remove all indentation changes in the patch.

Also why does the path in the patch file start with "src/org/openstreetmap/josm"? How do you create your patch files?

[skyper]

patch without indent adjustment

[skyper]

josm_route_aerial_update_v3.patch​ does not include the indent adjustments.

I am not happy with the alignment of the checkgroups in stop_position but this is the best I got.

I usually only create diffs but my header adjustment was off after the changes 5 month ago. Should be better now.

[skyper]

includes reservation for share_taxi routes

[skyper]

Just say reservation=* which is needed for share_taxi, so version 4​ includes it for route relations.

[skyper]

patch to harmonize chunk indentation (should be applied after main patch)

[skyper]

Still do not like the mixed up indentation so here is the single patch​, to be applied after the main patch.

[Klumbumbus]

Replying to skyper:

I usually only create diffs but my header adjustment was off after the changes 5 month ago. Should be better now.

So you copy the header manually into the file? For future patches could you please adjust your header template: replace the 4 spaces after the file name in line 3 and 4 by one tabulator, because the spaces block applying the patch?

[Klumbumbus]

In 16710/josm:

fix #19382 - Add website, operator, fee, opening_hours and reservation to route relations and/or aerialways, sort checkboxes in public_transport=stop_position preset better, based on patch by skyper

[Klumbumbus]

Replying to skyper:

I am not happy with the alignment of the checkgroups in stop_position but this is the best I got.

Yeah, that looked ugly, like someone trying to align words in colums in MS Word by spaces... It would look different with different Look and Feel or different OS anyway.

The texts of aerialway:occupancy are actually different for each type.

All new chunks were not needed. This only makes the patch and the resulting preset harder to understand.

[skyper]

Replying to Klumbumbus:

Replying to skyper:

I am not happy with the alignment of the checkgroups in stop_position but this is the best I got.

Yeah, that looked ugly, like someone trying to align words in colums in MS Word by spaces... It would look different with different Look and Feel or different OS anyway.

Maybe, an enhancement for <checkgroup> the option width="" or col_width="" to define the width of each column (element). Multiple value with separator semi-colon could be allowed, to define a sequence of different widths.

The texts of aerialway:occupancy are actually different for each type.

Nice, spot.

All new chunks were not needed. This only makes the patch and the resulting preset harder to understand.

I like the concept of chunks as I do not have to repeat (copy & paste) myself all the time. It is much easier to change/update certain tags completely, though, I see you point. Is creating single item chunks to not repeat the whole item all the time an accepted solution? This way, you still get all the information about the included tags but not the complete item. Speaking of readability, a file with over 8000 lines is not the easiest way.

[Klumbumbus]

In 16711/josm:

see #19382 - Fix chunk indentation (patch by skyper)

[Klumbumbus]

Replying to skyper:

Maybe, an enhancement for <checkgroup> the option width="" or col_width="" to define the width of each column (element). Multiple value with separator semi-colon could be allowed, to define a sequence of different widths.

Consecutive (or all) checkgroups in one item would need to share a common width per column automatically. (The recycling preset would profit from this feature too.)

I like the concept of chunks as I do not have to repeat (copy & paste) myself all the time. It is much easier to change/update certain tags completely, though, I see you point.

I like chunks too, but only when they are useful. They are useful for groups of several lines which are used a lot in different items e.g. ("name_ref_operator" or "link_contact_address"). This reduces the file size without adding too much complexity because you quickly know what the chunk contains.

The problem with chunks is, if you don't know by heart what the chunk contains you need to jump around in the preset file from actual item to chunk back and forth which is a pain. This is especially a problem for chunks which are seldom used. Chunks which are used only a handful of times in the whole file are not needed anyway.
Regarding the example of aerialways:* tags, all are used within only 100 lines. Putting them in chunks and moving away makes it all worse. Also such items are changed like every 5 years. It is no problem to copy a change to the next following 5 items then (we have find, replace and replace all for such a task too).
If you change a chunk you need to check if the change makes sense for all items where it is used, this becomes complex when chunks are used in chunks. In the end the advantage of the chunk has turned into a disadvantage.

Is creating single item chunks to not repeat the whole item all the time an accepted solution? This way, you still get all the information about the included tags but not the complete item.

Only for very complex ones which are used several times like opening_hours.

[skyper]

Replying to Klumbumbus:

Replying to skyper:

I am not happy with the alignment of the checkgroups in stop_position but this is the best I got.

Yeah, that looked ugly, like someone trying to align words in colums in MS Word by spaces... It would look different with different Look and Feel or different OS anyway.

Actually, I did not try to use "tabulators". Might work?

[Klumbumbus]

Replying to skyper:

Actually, I did not try to use "tabulators". Might work?

Nah, I guess it could still look different on different LaF/OS. And thinking about translations it is not acceptable.

[skyper]

See #19472 for a request for column width.