Closed plepe closed 9 years ago
I am curious about the set command in pgmapcss as we (the Brazilian OSM community) are working on a national rendering with pgmapcss as pre-processing for mapnik. As we do not have a working render yet due to lack of available disk space and processor capacity, much experimenting are done with semi-compatible software (i.e. in JOSM).
will the following statement bring any strange behaviour?
way[highway=unclassified][surface=unpaved] { set "DNIT:Class" = NAT; } way["DNIT:Class"=NAT] { /* my magic here */ }
No, that's expected usage of the set statement. The only unexpected behaviour is, that it will result in a query from the database for objects with tag "DNIT:class"=NAT too. I recommend prepending tag names with a dot, these will not generate queries to the database.
In JOSM you can't set tags, but you can do (which is compatible with pgmapcss):
way[highway=unclassified][surface=unpaved] {
set ".DNIT:Class";
}
way."DNIT:Class" {
/* my magic here */
}
Note: I'm not sure if you can use quotes (either JOSM or pgmapcss).
Btw, you might be interested in version 0.10 (which I just released), you no longer need a local database import, so disk space should not be an issue.
Thank you, you confirm my intention, the actual stylesheet adds set "DNIT:Class" on roads without "DNIT:Class" set previously, that way a mapper can override the renders behaviour if necessary.
In otherwords, if the mapper knows the way is "Implantada" and not "Leitão Natural", he can add "DNIT:Class"="IMP" on a road the renderer would guess to "DNIT:Class"="NAT". These tagging excemptions is necessary as in some remote places, one would want to classify a road with highway=secondary even if it is of the lesser quality due to transport importance.
I just poked the one hosting the temporary test machine to see if we might get a test rendering running based on 0.10, if not than we need to wait for OSMF Brasil to get hold of a proper server.
Currently, objects are processed serial, so that a set tag statement on a parent (or otherwise related object) can not be read by parent_tag(). E.g.
With the implementation of this issue, the first statement should be executed for all (possible) parent objects, and then the second for all the ways.