osm-carto for TagInfo #961
Comments
|
Hmm, interesting idea, but it would mean extra maintenance effort. I don't think we can automatically generate it. Opinions? |
|
It should be possible. AFAIK finding used tags in automatic way was already done to generate #204 (and it is using a simple regexp). Generating optional fields would be harder, but even this may be doable. |
|
2014-09-19 17:48 GMT+02:00 math1985 [email protected]:
maybe we can filter this from the "select" queries? Or from the filter |
Doubtful. We transform tags in the SQL, and thanks to the legacy SQL, we'll do stuff like transform https://github.com/sabas/doesitrender checks for a pre-defined list of keys and finds values. And I bet it gets some of our usage wrong. #204 had a fairly high error rate initially, which was solved by removing false positives from the list manually. If someone wants to write code to produce a list, I'd welcome it, although I'm still not sure that within the repo is the best place to track it. I just don't think it's possible without interpreting the SQL and MSS in full. |
|
Is the code from |
|
I would say that @pnorman is correct that this is unlikely to be possible automatically given the reworking of tags in the SQL. It is still a goal of mine to have a legend file for this repo, as I now have for other projects that I work on. The legend files are hand-curated but contain the 'output' of the tag-mangling, so won't be suitable for TagInfo either. So we'll end up with two hand-maintained data files for the repo, but for me the legend file is a much higher priority (especially given that the legend on osm.org no longer matches the colours used here). |
|
I made a script that works pretty well. But what should be done with tags that are changing rendering of other tags? For example name=* should be listed as rendered - but what about tags that have some effects in really weird combinations? Should it be listed or manually filtered? For reference: [barrier=hedge; historic=any_tag_value] [barrier=hedge] with the same closed way [aeroway=any_tag_value; amenity=place_of_worship; area=yes] - note missing icon for PoW - it may be fixed but it is probably better to work on other things
|
|
Taginfo is not build to be super precise but to give an overview that a project does something with the tag. |
|
@mkoniecz I see some of the problems you mean (at least the last one with the |
|
So first stage - generating a reliable list from OSM data is finished. On https://github.com/mkoniecz/CartoCSSHelper/blob/master/style_specific/default_osm_style.rb there is a list of OSM tags considered by style, tag may be in one of three categories:
Each tag is listed as 'Status.new('key', 'value', :category, example_of_composite_tags_if_relevant),' It is possible that some of rendered tags are missing - in this case feedback would be really useful. Note that it is not exactly what is rendered by style - list was modified to hide effects of some bugs - for example matkoniecz/CartoCSSHelper@d1fc159 Tags that are acting like area=yes (except area=yes) are not listed (see #961 (comment) for description of the problem). In the near future I will be unable to work on the second stage - converting this list into format usable by Taginfo. |
|
I don't think that keeping such a file in line with the current version of the style would be a problem, if pull requests would require changing this file as well. The main effort would certainly be the creation of the initial version. |
|
A few thoughts on the matter:
|
|
I like the Idea of having a Text file which is ordered by layer and a script which will generate the Taginfo file. In this case it would even be possible to add tag combinations which are currently not supported in Taginfo project format. |
|
I'm iffy on if this is worth the maintenance burden. If we do do it, we should make sure that we can build a legend from it, and that we're not doing it as JSON, because that will lead to difficult to solve merge conflicts. |
|
While it would be nice to have osm-carto on Taginfo, this is beyond our manpower and nobody seems to be interested to even start, so I close it now. If there will be some automatic solution or somebody ready to take care of it, it can be reopened. |
|
My "poor man" suggestions: just add the osm keys: not perfect - Proof Of Concept : $ cat project.mml | grep -oP "tags[^']*'.+?'" | cut -d"'" -f2 | cut -d"=" -f1 | sed 's/"//g' | sort -u
addr:unit
advertising
capital
denomination
ele
emergency
entrance
ford
generator:source
height
highspeed
iata
icao
indoor
intermittent
leaf_type
memorial
operator
population
power_source
public_transport
recycling_type
seasonal
tower:construction
tower:type
usage
wetland
$ cat openstreetmap-carto.style | grep '^[[:blank:]]*[^[:blank:]#;]' | tr -s ' ' | cut -d' ' -f2 | awk '!/(z_order|way_area)/' | sort -u
access
addr:housename
addr:housenumber
addr:interpolation
admin_level
aerialway
aeroway
amenity
barrier
bicycle
boundary
bridge
building
construction
covered
foot
highway
historic
horse
junction
landuse
layer
leisure
lock
man_made
military
name
natural
oneway
place
power
railway
ref
religion
route
service
shop
surface
tourism
tracktype
tunnel
water
waterwayfor detecting the |
|
OK, more automatic tools would be needed. What would be the goal however, just the information in Taginfo that osm-carto uses this tag or what? |
|
@ImreSamu |
|
Sorry for not being clear enough My idea:
My Minimal result :
Extra: We need a strict SQL guideline for a good parsing. imho:
Sorry for the confusion...
imho: there are another minimal project descriptions here and according to the "taginfo" |
|
I agree that you can start with this and fine tune it later on. What would you need from this project to make it happen in Taginfo? I guess you can make it on your own, because the source is publicly available, but if there is something you need, just tell and we can think (and I will reopen this ticket). We could host the script, but maybe it's more related to Taginfo? |
|
my simple code is here #!/bin/bash
set -o errexit
NOW=$(date +%Y%m%dT%H%m%SZ)
tempfile=$(mktemp /tmp/_taginfo_.XXXXXXXXX)
cat project.mml | grep -oP "tags[^']*'.+?'" | cut -d"'" -f2 | cut -d"=" -f1 | sed 's/"//g' > $tempfile
cat openstreetmap-carto.style | grep '^[[:blank:]]*[^[:blank:]#;]' | tr -s ' ' | cut -d' ' -f2 | awk '!/(z_order|way_area)/' >> $tempfile
sort -u $tempfile -o $tempfile
cat << EOT > taginfo.json
{
"data_format": 1,
"data_updated": "$NOW",
"project": {
"name": "openstreetmap-carto keys",
"description": "A general-purpose OpenStreetMap mapnik style, in CartoCSS",
"project_url": "https://github.com/gravitystorm/openstreetmap-carto",
"contact_name": "",
"contact_email": ""
},
"tags": [
EOT
cat $tempfile | awk 'NR > 1 { printf(",") } { printf("{\"key\": \"%s\" }\n ", $1) }' >> taginfo.json
cat << EOT >> taginfo.json
]
}
EOT
rm -f "$tempfile"this is working for the current code in this repo, but has some limitations
so sometimes need a little tunning on the Regexp. So
if the project team prefer the python implementations, there are some basic examples ( need to add some |
|
I prefer Python, since it makes it more platform independent. You think it's better to add it into the style then develop and run it independently? This way or another I reopen the issue, since there is a genuine progress. |
|
The json file could be updated before release (like the chicago preview image here in the repository). |
|
I have started working on this ...
see more : #3151 Don't expect fast result ... |
|
The name should be changed like "openstreetmap.org carto keys" -> "OpenStreetMap Carto keys". |
|
And remove "mapnik" from the title. It is not complete wrong worded, but there are too many which calls this style still "mapnik" |
|
Right, I would change it like this: |
|
a little statistics ... "new keys" == new keys in the ~ taginfo-project file
|
|
updated statistics ...
|
|
The demo project above is no longer at the link (http://as-af.taginfo-dev.opengeodata.hu/projects/osmcartov2#tags), and the related PR was closed (#3151). It does not look like there is an easy way to do this. There is now a maintained legend of most features rendered in this style at:
And most feature pages on the wiki have a rendering sample, which can be used by taginfo's taglists. So, is this still needed, or can we close this issue? |
|
Closing for the reasons above. |
|
Whilst there may not be the appetite for the OSM Carto developers to advertise what keys and values this style uses at taginfo, I think it's worth sharing my experience of doing exactly the same thing with a map style derived from OSM Carto:
|
|
I have written about the matter extensively some time ago here and have to disagree with @SomeoneElseOSM here on some points. An accurate index of what tags are affecting rendering and how is hard to produce for most non-trivial map styles. What you have produced for your map style might be useful for you as the style developer in a single developer project to organize your notes on features and keep track of them. But if you compare this with the analysis on https://imagico.de/map/styleinfo/#style=ajt§ion=style which is fairly incomplete due to the complex tag interpretation you do with its many catch-alls - you will see that it covers only a small part of the logic based on which tags are interpreted and affect the rendering result. For example for which only describes the interpretation of the tag on roads, not on various POI types where it affects rendering as well. Usefulness of such a selective documentation in a larger project like this would be rather limited. It also seems a bit weird that you reject the hand maintained style documentation on the wiki because it is not regularly maintained but at the same time promote a system of hand maintained documentation in the hope that it will be more regularly maintained despite obviously being less accessible for editing for the average style user. I do not want to discourage anyone from analyzing the way OSM-Carto interprets tags in a systematic fashion and to publish the result. This is done way too little and the more work (manual human work) in that direction is done the better (for OSM-Carto but also for OSM in general). But for producing a machine readable index of what tags OSM-Carto interprets and how (which is what a taginfo.json file is in a very simplified form) i have little doubt that systematic automated testing is the most viable approach. |
|
@imagico As an aside, perhaps it's worth writing about https://imagico.de/map/styleinfo/ somewhere a bit more public so that more people know about it? As an aside, I've no idea what https://imagico.de/map/styleinfo/#style=ajt§ion=style is showing, and do wonder whether it's taking into account the lua preprocessing that that style uses at all. You have said that "An accurate index of what tags are affecting rendering and how is hard to produce for most non-trivial map styles". To be clear, "and how" is something you have added to the requirement yourself there, and that can be complicated (especially when tags are used in combination - "access=private; foot=yes" for example) but the what ("does style X know about tag Y") is not difficult. I don't entirely understand the rest of your comment but it seems to be "doing a perfect job would be hard"? If that's what you're trying to say I don't disagree, but it's not really relevant. |
I am not sure what you mean by 'more public'. I don't remember if this specifically was mentioned on weeklyOSM - but most people involved in OSM map style design read my blog so are aware of this.
Of course it does, as written in the blog post - the analysis can only exclude the database import step if the database content fairly directly represents the OSM data. That is not the case with your style. Which makes the analysis several times slower than for the other OSM-Carto forks. If the Styleinfo UI does not work for you you can use the API directly - for example https://imagico.de/map/styleinfo/api/ajt/renderings/?key=amenity&zoom=19&secondary_key=brand gets you all the renderings of will get you the rendering of
The 'how' is primarily about if a tag is interpreted as a primary tag or as a secondary tag. But also just producing a list of tags that - when they exist in the data - under some circumstances affect the rendering result, is not much easier if it is supposed to be reliable. In other words: A detailed how is essentially an automatic byproduct of reliably determining if. Of course just producing a list of tags that might be interpreted by the style because there is code somewhere literally referencing these tags is much easier. Not as easy as the list of keys (as discussed above) because you need to look at both the SQL and the MSS code but still easy compared to determining what actually leads to a rendering difference. Between #3731 and #4591 we had for example code in the style referencing healthcare tags without there being actual rendering based on those. Therefore such a list is practically of rather limited use. |
The new feature of Taginfo allows to give information about usage for a selected tag in a project
openstreetmap-carto is a natural fit
http://wiki.openstreetmap.org/wiki/Taginfo/Projects
I did a list some time ago, perhaps it's useful https://github.com/sabas/doesitrender/blob/gh-pages/taglist.md
The text was updated successfully, but these errors were encountered: