logo separator

[mkgmap-dev] Question (RFC): Is function [has-period-ended] an option?

From AnkEric eric_internet at casema.nl on Sat Mar 21 09:42:08 GMT 2020

Mapillary, Survey, local knowledge: road closure in future from date_start
till date_end

https://www.mapillary.com/map/im/a4s9RiyhwiYQ2KecMuD2HQ

I can see this Closure on the Map by "red dots" showing on the way.
Hoover over or Click to show [opening_hours] or [access:conditional].
This is a "Warning" only, not implying routing is not possible.
So if I forget to Delete these tags afterwards (by the end of construction
period): no harm.
Also planning a future route is still possible (routing is possible) if my
trip is after construction period has ended.

<http://gis.19327.n8.nabble.com/file/t344065/Closed_by_opening_hours.png> 

In JOSM:

<http://gis.19327.n8.nabble.com/file/t344065/Closed_by_opening_hours_JOSM.png> 

My Challence:
I have to Delete these tags once Construction Period has ended:
access:conditional=no@ (2020 Mar 20 18:00-24:00;2020 Mar 21-22 00:00-24:00;
2020 Mar 23 00:00-06:00)
fixme=TO BE DELETED Construction period ENDS 2020 Mar 23 06:00

The fixme is a reminder warning: PLEASE DELETE by "2020 Mar 23". Don't
forget, since this is sloppy and poluting the map.

The requested Function should return an Offset between
[LAST_DATE_ALSO_HAVING_YEAR_SPECIFIED] and an Offset_Date ("yyyy mmm dd").
So the Challenge is to find the "Last date" ("yyyy mmm dd") in a complex
opening_hours or conditional  value.
The value to supply is up to me:
${bicycle:conditional}
${access:conditional}
${opening_hours}

In above example Value_Last_Date to be found is: "2020 Mar 23".
Hours are to be ignored (not relevant).

This - example - warning has not yet "ended". It's still active!
Next week I should Delete it.

FWIW: OpenFietsMap also shows these warnings (it was introduced by OFM).
Only disadvantage: only Rendered on cycleways. IMO it should be Rendered on
ALL ways.

And I hate running into a construction-closure-trap! Most specific on
bicycle these closures should be avoided in trip-route-planning.






--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html


More information about the mkgmap-dev mailing list