-
Notifications
You must be signed in to change notification settings - Fork 819
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add rendering for amenity=* and office=* #108
Comments
Il giorno 09/ago/2013, alle ore 03:41, Jason Remillard [email protected] ha scritto:
or craft or shop |
Yes, I meant to include shop too. |
I fixed the shop portion of this with #117. I might submit another pull request with a generic rendering of amenity= although unlike shop=, it'll probably only be named amenities. I can't find any instances of craft= or office= already being rendered |
Craft= and office= are not rendering. That will be very good improvement to start render them. |
I fully agree with this, when the pull request of @oddityoverseer13 will be ready, doing the same thing for office=* and amenity=* should be easy? |
We dont't want to render spelling mistakes, so we should come up with a list of tags to render. |
Yea, we can do something very similar to #604 for office, amenity, and craft. The script I wrote can be easily adapted for that. Maybe we can come up with a different generic office, amenity, and craft icon? |
Craft is not in the database, so cannot be done straightaway. I would focus on office and amenity first. Not sure if a blacklist-system for amenity would work well, because the amenity thing key contains all kind of different things and we might not want to render most. |
for bigger office areas we show the information with the landuse=commercial tag the various amenities and crafts are so different in nature that an icon doesn't give you any more information, we could simply show a name label, but then this would also display objects with typos in the tags (not desirable for this map) |
It also gets us into a tagging mess, because |
the tag comes from the German community and was intended to mean "Handwerk" which is basically a medieval concept but still valid in today's reality in Germany at least (I guess in most of Europe). My dictionary gives both terms, trade and craft, for the German word, not sure what the differences are. It has also to do with guilds, or nowadays the IHK (Industrie- und Handwerkskammer = ~ chamber of industry and trades/crafts). It is mostly not about handy craft. |
|
2014-06-22 23:33 GMT+02:00 Paul Norman [email protected]:
I agree that the description of craft in the wiki is poorly drafted, e.g. The specific value craft=agricultural_engines was also emerging from One of the reasons why "craft" was chosen as a key is also wikipedia I only at the end of the article there is a reference to trade [3] which If the current term "craft" is not well chosen for what it is intended to [1] [2] http://de.wikipedia.org/wiki/Handwerk -> |
Is there a difference in US and UK usage of the words "craft" and "trade"? Linguee.com is useful to find out how a term is used and translated on the web. Of course, it depends on the texts that are available, which may not always have been translated very well... "Handwerker" is a craftsman (or plural craftsmen). "Handwerk" is not clear: "craft" is used about 47% of the time, and "trade" about 35%. But the other way around, "craft" is translated as "Handwerk" nearly 75% of the time, while "trade" is translated mostly as "Handel" (50%) and only infrequently as "Handwerk" (6%). I get the feeling "craft" is OK to describe the German concept of Handwerk. Maybe "trade" would be more correct and sound better to a native speaker, but trade has more and stronger additional meanings which might confuse mappers. It's still true that some of the things tagged with craft=* probably should be tagged as something else. |
I agree that some tags don't seem to belong in craft at all, but I think the generall idea was to use craft for local traditional small scale production and man_made=works if it is industrial (e.g. brewery). I guss a lot of stuff ends up in craft= simply because man_made=works is even worse defined. I mean how Am I supposed to tag a sawmill? man_made=works + product=wood? I think for this tag to be used more it need something like works=sawmill/chemical_plant/brewery/... and not just product=*. |
These are the 60 most used amenity values that are not in the map style yet (Groups of 10):
I removed "yes" and "abandoned", hope I missed nothing worthwhile. |
Thank you for the overview, very interesting. What does amenity=residential mean? This is also very related to #660. Instead of making decisions for the individual cases, I think it would be good to have some strategy on how to decide which map features to add. |
Here the values that are in the code, with empty lines to show what's missing
|
I'm sure it is an error. Maybe something that happens when an old value is still in an editor, after tagging landuse or highway=residential. But many seem to be combined with buildings, so could be that this should say these are "residences"?
Yes indeed. amenity is a kind of catch-all, but some of the other tags are also not very uniform. Maybe we could come up with groups of POIs that should be treated in a similar way (not just in key:amenity)
|
I think the hardest ones are the government/social facilities. We have public_building, townhall, social_facility, community_centre, nursing_home, retirement_home, refugee_housing, youth_centre, etc. I think the name of these should be rendered on the map. But should they also get an icon? My gut feeling says that they would look better without icon, but I can't quite tell why. Also, would a text without icon look fine if these amenities don't take up a full building? |
Yeah, they do serve a public interest. Funnily, I had the same thought, that they don't need an icon! Maybe it's because the icons would not be easily recognizable or intuitive? How would an icon for a nursing_home look? Also, social_facility has a lot of sub-tags to replace many of the other tags: |
See also https://trac.openstreetmap.org/ticket/4420 (veterinary), https://trac.openstreetmap.org/ticket/2199 (brothel), and https://trac.openstreetmap.org/ticket/4742 (motorcycle_parking). |
I've just noticed https://map.atownsend.org.uk/maps/map/map.html renders office=company as a dot and a name. Perhaps the implementation can be reused. |
Would you like to prepare the code? That would help a lot. |
I provided a suggest icon for a bbq #2996 a week ago is some one able to check it for me to see if it is suitable and maybe implement it? |
I think this issue should be renamed to "Render amenity=* as dots + names". Let's review first comment #108 (comment) :
The only thing which stay left to discuss here is generic dots for amenities which don't have separate tickets for own icons. |
Can someone compile a list of amenity tags that are currently not rendered and could be added as a dot + name? The one from @daganzdaanda is a bit out of date now. If so, I will prepare a PR similar to #3163. |
After review of a topic, I think we shouldn't use dot-rendering for any amenity=*. This tag is so diversified that generic-dot may be confusing. We should just discuss using dedicated icon if we want to add rendering for some amenity. |
I partially disagree. Yes, we would like to have icons for amenity tags (BTW, office= tags are not an exception, there are some good candidates for an icon as well) but the priority should be in supporting all documented or popular tags in the first place. What I propose is a 2 stage approach. First we implement all missing tags as dots and then, one by one, add icons for them. |
I looked at all issues with "amenity-points" label https://github.com/gravitystorm/openstreetmap-carto/issues?page=2&q=is%3Aissue+is%3Aopen+amenity+label%3Aamenity-points @andrzej-r Can you give examples which tags do you consider? |
@Tomasz-W there are over 9000 amenity tag values: https://taginfo.openstreetmap.org/keys/amenity#values Over 110 are documented in https://wiki.openstreetmap.org/wiki/Key:amenity. ID currently have 25 presets for amenity=*. As I mentioned in #3163, my (new) proposal is to have a catch-all clause rendering all amenity=* and office=* tags with a simple dot+name. On top of that we can special-case any other tag values (icons, custom filtering/rendering options) just like we are doing it now. Even if we were to use an opt-in approach, it is still useful to have a fall-back rendering for tags do not have an icon for just yet. |
While office sounds OK for me to always be rendered with a dot, amenities are too different. It might be another kind of eating place, street furniture or almost anything else. Therefore I would be more careful when rendering amenities and do it only for whitelisted values. Probably some of them need to move to the new keys to make it more clear what they really are. |
sent from a phone
On 7. Apr 2018, at 11:28, kocio-pl ***@***.***> wrote:
While office sounds OK for me to always be rendered with a dot,
I could imagine limiting these to large offices, i.e. on areas and >=limit
Generally, while bigger offices can be landmarks, most offices are IMHO not significant enough for this general style.
|
dieterdreist, you have to tweak both icon and label rendering paths. Not saying it is not possible (I tried it before) but the combinations quickly pile up. For example, office= tags are quite often combined with landuse= (not just building= tags) and there are likely a lot of other corner cases. Also, without rendering at least an icon or dot you will often not see the tag at all - in congested areas labels often hidden even at z19. Do more people agree that dots on the buildings are undesirable? If so, do you have any ideas for a solution? |
This sounds like a tagging mistake, can you give an example of place where this tagging is correctly used? |
There are many such unexpected tag combinations in use. Given their popularity I wouldn't automatically dismiss them as tagging errors. One reason is lack of support for office tags in carto, so there is no visual feedback to the mappers. Edit: I noticed another use case - some ways are tagged with office=* only (no building or landuse tags). Edit 2: or plain area= or indoor mapping like here. I've even seen spotted a combination of landuse=school, amenity=school and office=educational_institution, although I'm OK treating this one as a tagging issue. |
For me, this issue is resolved by #3163 . |
I think we should still consider the last three individual amenities in the initial post. |
@matthijsmelissen I agree, but:
This meta-issue is unnecessary in this situation. |
Alright, happy to close this item! |
Hi,
Any point that has an amenity or office tag and a name tag, should at least get its named rendered even if we don't have an icon at max zoom.
Most of the POI's in the mall are not rendered.
http://osm.org/go/ZfJD0RleX--
The text was updated successfully, but these errors were encountered: