Mapcss: allow retrieving current year

[Famlam]

What steps will reproduce the problem?

Have (custom) mapcss validator rules that check for e.g.:

• start_dates in the future (e.g. start_date=2103 instead of 2013)
• opening_dates on *=construction objects in the past (building=construction + opening_date=2020-04-22)
• *:conditionals expired in the past (e.g. bicycle:conditional = no @ (2021 Nov 22 - 2021 Dec 04))

Have to update these rules every year to adjust their year.

What is the expected result?

It would be great to have a mapcss function that can just return current year as an integer (according to the users operating system and corresponding time zone should be good enough for 99.99999% of the cases).

That way, the aforementioned use cases can be used without yearly manual update. (All other parts of the rules can be dealt with via e.g. regexp_match, to_int, adding or subtracting years, sorting (in absence of min()/max() functions), etc...)

What happens instead?

Every year at Jan 1, update all year-dependent rules manually

Please provide any additional information below. Attach a screenshot if possible.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2023-12-22 12:48:53 +0100 (Fri, 22 Dec 2023)
Revision:18924
Build-Date:2023-12-23 02:31:03
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (18924 nl) Windows 10 64-Bit
OS Build number: Windows 10 Home 2009 (19045)
Memory Usage: 576 MB / 2012 MB (179 MB allocated, but free)
Java version: 17.0.9+8-LTS, Azul Systems, Inc., OpenJDK 64-Bit Server VM
Look and Feel: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
Screen: \Display0 1920×1080 (scaling 1.10×1.10)
Maximum Screen Size: 1920×1080
Best cursor sizes: 16×16→32×32, 32×32→32×32
System property file.encoding: Cp1252
System property sun.jnu.encoding: Cp1252
Locale info: nl_NL
Numbers with default locale: 1234567890 -> 1234567890
VM arguments: [-Djpackage.app-version=1.5.18906, --add-modules=java.scripting,java.sql,javafx.controls,javafx.media,javafx.swing,javafx.web, --add-exports=java.base/sun.security.action=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.plugins.jpeg=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.spi=ALL-UNNAMED, --add-opens=java.base/java.lang=ALL-UNNAMED, --add-opens=java.base/java.nio=ALL-UNNAMED, --add-opens=java.base/jdk.internal.loader=ALL-UNNAMED, --add-opens=java.base/jdk.internal.ref=ALL-UNNAMED, --add-opens=java.desktop/javax.imageio.spi=ALL-UNNAMED, --add-opens=java.desktop/javax.swing.text.html=ALL-UNNAMED, --add-opens=java.prefs/java.util.prefs=ALL-UNNAMED, -Djpackage.app-path=%UserProfile%\AppData\Local\JOSM\JOSM.exe]

Plugins:
+ OpeningHoursEditor (36126)
+ imagery_offset_db (36126)
+ pbf (36176)
+ pt_assistant (632)
+ reverter (36126)
+ tageditor (36126)
+ turnlanes-tagging (0.0.5)
+ undelete (36126)
+ utilsplugin2 (36178)

Map paint styles:
+ https://josm.openstreetmap.de/josmfile?page=Styles/Potlatch2&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Lane_and_Road_Attributes&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/PublicTransport&zip=1
+ %UserProfile%\Documents\tijdelijke bestanden\josm-eigen.mappaint.mapcss
+ https://josm.openstreetmap.de/josmfile?page=Styles/Sidewalks&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/ParkingLanes&zip=1

Validator rules:
+ %UserProfile%\Documents\tijdelijke bestanden\josm-eigen.validator.mapcss
+ https://josm.openstreetmap.de/josmfile?page=Rules/SuspiciousSwimming_Pool&zip=1
+ https://raw.githubusercontent.com/osm-fr/osmose-backend/master/plugins/TagFix_Destination.validator.mapcss
+ https://raw.githubusercontent.com/osm-fr/osmose-backend/master/plugins/Colour.validator.mapcss
+ https://raw.githubusercontent.com/osm-fr/osmose-backend/master/plugins/notprefix.validator.mapcss
+ https://raw.githubusercontent.com/osm-fr/osmose-backend/master/plugins/TagFix_MultipleTag2.validator.mapcss
+ https://raw.githubusercontent.com/Famlam/OsmMapcssValidationNL/main/netherlands.validator.mapcss

Last errors/warnings:
- 00000.538 W: extended font config - overriding 'filename.Myanmar_Text=mmrtext.ttf' with 'MMRTEXT.TTF'
- 00000.540 W: extended font config - overriding 'filename.Mongolian_Baiti=monbaiti.ttf' with 'MONBAITI.TTF'
- 00000.995 E: java.security.KeyStoreException: Windows-ROOT not found. Oorzaak: java.security.NoSuchAlgorithmException: Windows-ROOT KeyStore not available

[gaben]

Yeah, that would be great, but while writing a MapCSS syntax highlighter plugin for IntelliJ, I see more and more divergence from the so-called 'official' ​MapCSS spec.

The question is if it's desired. In my opinion, it's not an issue, just needs to be discussed with a broader audience, who also consumes MapCSS. I see that each application has its implementation and extensions, so the language spec is just a recommendation at this point, making harder the general use.

[Famlam]

I understand your point, but I think that that's completely abandoned. The ​website is offline, the last update to 0.2 was 2016 (mailing list: 2017) and I don't find anything about a version 0.3 or 1.0. Practically almost none of the functions of JOSM (of which this would be one) exists in the proposed mapcss ​functions list.

[stoecker]

I fear that getting a "standard" is impossible in OSM somehow. We tried several times but any attempt to work together was never reciprocated (either presets, styles or other stuff). Sadly all the parties do their own. So while I do not like this I accepted it. Thus adding extensions to MapCSS should not be a concern. Only the fact, if it's a useful extension matching the overall design or not, really counts.

P.S. MapCSS replaced the internal format not because it's somehow standard, but because it was simply better than the old XML design ;-)

[taylor.smock]

Replying to gaben:

Yeah, that would be great, but while writing a MapCSS syntax highlighter plugin for IntelliJ, I see more and more divergence from the so-called 'official' ​MapCSS spec.

Really, the only thing I would care about is "does a MapCSS file written to spec work in JOSM". If the answer is yes, then we are OK. If the answer is no, then we should fix that.

With that said, I think JOSM is the only major consumer of MapCSS left. I don't mind have specific extensions that make mapping easier. I would like to see Rapid/iD support MapCSS, but I don't think that will ever happen.

[stoecker]

Replying to taylor.smock:

With that said, I think JOSM is the only major consumer of MapCSS left. I don't mind have specific extensions that make mapping easier. I would like to see Rapid/iD support MapCSS, but I don't think that will ever happen.

Well, don't forget mapnik (i.e. the openstreetmap maps). That's the origin and major user I think. Thought there will be little changes regarding extensions from this side.

[skyper]

See also #21429 and #22412.