Opened 3 years ago
Last modified 3 years ago
#21193 new enhancement
MapCSS: distance function
Reported by: | skyper | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Core mappaint | Version: | |
Keywords: | mapcss distance | Cc: | taylor.smock |
Description
This came up in #21172.
Would it be possible to make this function available in mapcss? Atm, I think about validator like #17188 or checking that
footway=sidewalk
has a nearby main road, though, it might be useful for styles, too.
Probably. How would it be used?
Possible example:
node[bus=yes][public_transport=stop_position] !<some random symbol, e.g. □>(0, 5) node[highway=bus_stop] { throwError("Bad public transport stop"); }I can't think of a good way to just make a function, as I don't think our MapCSS implementation would allow us to parse recursive MapCSS, although I could be wrong (I haven't checked). Example:
node[bus=yes][public_transport=stop_position][distance(node[highway=bus_stop], 0, 5)] { throwError("Bad public transport stop"); }The function definition would look something like this:
public List<IPrimitive> nearbyPrimitives(Predicate<OsmPrimitive> predicate, double minDistance, double maxDistance)
Attachments (0)
Change History (2)
comment:1 by , 3 years ago
Cc: | added |
---|
comment:2 by , 3 years ago
Honestly, I'd probably go for the list of objects with distances, since it is the most extensible. The only issue would be parsing the list (if showing something in the paint style).
So instead of
public List<IPrimitive> nearbyPrimitives(Predicate<OsmPrimitive> predicate, double minDistance, double maxDistance)
it would be
public List<Pair<IPrimitive, Double>> nearbyPrimitives(Predicate<OsmPrimitive> predicate, double minDistance, double maxDistance)
or (since we probably don't have special casing for Pair
)
public List<List<Object>> nearbyPrimitives(Predicate<OsmPrimitive> predicate, double minDistance, double maxDistance)
Example:
node[bus=yes][public_transport=stop_position][count(distance(JOSM_search("type:node highway=bus_stop"), 0, 5)) != 0] { throwError(tr("Way {0} is {1}m away", get(get(distance(JOSM_search("type:node highway=bus_stop"), 0, 5), 0), 0), get(get(distance(JOSM_search("type:node highway=bus_stop"), 0, 5), 0), 1)); }
But yes, there is a reason why more complicated checks are implemented in Java.
Good points.
would work but what exact answer do I expect: boolean, a number of object, the closest object or a list of objects with distances?
Eventually, it is better as a Condition selector with new symbol
□(0, 5)
or even options for mathematical functions to define different area than only circles.Oh, and how to check if these objects have identical tags like same
name=*
orref
. The more I think about it the more tricky it gets. As it looks complicated I understand why java code is used, directly.I thought about using it for checks on side paths like
*=use_sidepath
,cycleway=separate
,footway=sidewalk
andis_sidepath*=*
which would be interesting for styles as well.In case of simple validator checks, I guess
distance("", min, max)
withJOSM_search
inside""
and a boolean answer would do the job.