Re: [Tagging] Feature Proposal - RFC - relation type=sled
Philipp Spitzer wrote: > I like to propose > https://wiki.openstreetmap.org/wiki/Relations/Proposed/Sled (which is > actually a quite old proposal) which tries to overcome the shortcomings > of piste:type=sled (without replacing it). > > I would be happy if you could provide thoughts/comments in the > corresponding wiki page (preferred) or here. This seems to be somewhat similar to the recent discussion about using site-relations for camp-sites. Some people think that what I do in OpenCampingMap currently (using site relations) is an abuse of the "One feature, one OSM element" principle. (https://blog.geggus.net/2021/09/announcing-support-for-site-relations-in-opencampingmap/) Thus inventing another relation type for such loose bindings of distinct geographical features would make more sense than using a site relation. Let us call this relation, type=feature for now. A native english speaker will probably come up with a better name. The tagging would then be (In my case): type=feature feature=tourism:camp_site and in your case: type=feature feature=piste:type:sled The **feature** tag should then make clear that **only one element** tagged tourism=camp_site or piste:type=sled is valid in such a relation. This would then mark where all the distinct objects belong to. Would this be a viable path? Regards Sven -- Das Internet wird vor allem von Leuten genutzt, die sich Pornografie ansehen, während sie Bier trinken, es ist daher für Wahlen nicht geeignet (Jaroslaw Kaczynski) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Relations of type=site + tourism=camp_site
Jake Low wrote: > I would not recommend adding a node tagged tourism=camp_site into this > picture, as in my opinion it would be redundant with the site relation and > a violation of the "one feature, one OSM element" guideline. While this Approach would work well in OpenCampingMap, such objects will not get rendered on osm.org. This is why I think adding (only one!) node tagged tourism=camp_site to the site-relation would make sense. Regards Sven -- "and on the third day he rebooted into Linux-1.3.84" (Linus Torvalds, Easter Kernel Release 1996) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Relations of type=site + tourism=camp_site
Mateusz Konieczny via Tagging wrote: > So > https://www.openstreetmap.org/relation/13012999#map=19/49.12702/10.86422 > site relation is including nearby restaurant and shop? Right! > That are not actually part of camp site? Wellm, they are not part of it geographicaly because the are located outside the actual campground but they are part of it in organizational terms. Is this that hard to understand? > And just included there to manually do processing part of finding nearby > shops/restaurants? Wrong. They are not only nearby somethings but as I wrote above are parte of the site in organizational terms. Sven -- "Das ist halt der Unterschied: Unix ist ein Betriebssystem mit Tradition, die anderen sind einfach von sich aus unlogisch." (Anselm Lingnau in de.comp.os.unix.discussion) /me ist giggls@ircnet, http://sven.gegg.us/ im WWW ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Relations of type=site + tourism=camp_site
Yves via Tagging wrote: > Site relations are often used to models thing that aren't spatially > joined, like windfarms, universities... I can easily imagine it's > reasonable to use them for campings in some corner cases where a single > area doesn't work. Yes, let me clarify this with an example: E.g. This site has a working site relation (without tourism=camp_site removed): https://opencampingmap.org/#15/49.0815/7.9123/1/1/bef/node/3824691120 The camp_site node is https://www.openstreetmap.org/node/3824691120 Site relation is https://www.openstreetmap.org/relation/13009876 While it is currently tagged toilets=yes and openfire=yes this is not mandatory because evaluating the corresponding site relation will give us a toilet and a fireplace. So what I do with site relations here is basically the same I do with camp_site areas. With areas I check if any supported object is inside the area (spatial join) and assume that this is a feature of this particular camp_site. With site-relations this is even easier as I can consider all objects related to the site a feature of the camp-site in the relation. I think this is elegant especially in comparison to the alternatives suggested here like expanding the campsite polygon into areas open to the general public like reception desks, restaurants or even toilets also used by other facilities like sport-centers. Last but not least, what I do consider bad practise and show them as a bug in my map is stuff like this: * More than one camp_site object added to a site relation * Using site-relations in cases a multipolygon is sufficient * Camp-sites that contain others (not part of this discussion) Regards Sven -- "The only thing we have to fear is fear itself" (Franklin D. Roosevelt) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Relations of type=site + tourism=camp_site
Martin Koppenhoefer wrote: > multipolygons can solve any disjoint area problems, you only need a site > relation if some members are nodes or linear ways or relations. External objects of camp-sites are often node shaped. Sven -- "In my opinion MS is a lot better at making money than it is at making good operating systems" (Linus Torvalds, August 1997) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Relations of type=site + tourism=camp_site
Marc_marc wrote: > taking one random exemple : > https://www.openstreetmap.org/relation/13012999#map=19/49.12702/10.86422 > according to the parking name=*, the parking may be include in the > tourism=site_camp Yes but this is simply not as it is on the ground. The parking is not _part_ of the camp-site but for visitors as well as the restaurant and shop. They are not stritly cusomers only like the enclosed area. > if someone think that the restaurant and the shop are also part of the > camp site, then it's easy to extend the area to include those. Which is just plain wrong as they are not _only_. Regards Sven -- Das allgemeine Persönlichkeitsrecht (Art. 2 Abs.1 i.V.m. Art.1 Abs. 1GG) umfasst das Grundrecht auf Gewährleistung der Vertraulichkeit und Integrität informationstechnischer Systeme. (BVerfG, 1BvR 370/07) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Relations of type=site + tourism=camp_site
Mateusz Konieczny via Tagging wrote: > Yes, using site relation in addition to actual object breaks this rule > and it is undesirable (and site relations in general are problematic). Why do you think that "site relations in general are problematic"? > Is there some reason why this camp sites cannot be mapped as areas > if someone is doing such detailed mapping? Of course there are. The thing is that objects outside (usually ways and nodes) might be part of a particular camp_site. E.g. when a sport-center and a camp_site are sharing there sanitary buildings. I did not implement the support for this in OpenCampingMap just for fun. I really do think that there is a need for this. All the sites in the above changeset would need one or more additional redundant tags like restaurant=yes on the main node or way if a site relation is no longer an option. Regards Sven -- Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety (Benjamin Franklin) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Relations of type=site + tourism=camp_site
Marc_marc wrote: >> Ignoring the principle (which is not absolute anyway) > > sorry but reading "No two campings", I can only agree > that a campsite has only one tourism=camp_site tag and not 2 Shure. However I do not consider the site-relation a campsite itself but a collection of other objects outside the main are or node which are pat of the site. Sven -- Um Kontrolle Ihres Kontos wiederzugewinnen, klicken Sie bitte auf das Verbindungsgebrüll. (aus einer Ebay fishing Mail) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Relations of type=site + tourism=camp_site
Yves wrote: > Instead of type=site + tourism=camp_site, type=site + site=camp_site would > be less prone to objections, maybe. Well, wiki states that site=something is not recommended anymore. Sven -- All bugs added by David S. Miller Linux Kernel boot message from /usr/src/linux/net/8021q/vlan.c /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Relations of type=site + tourism=camp_site
Hello, about a year ago I implemented support for site relations in OpenCampingMap. My announcement from back then is at: https://blog.geggus.net/2021/09/announcing-support-for-site-relations-in-opencampingmap/ Now a recent changeset discussion is questioning my whole approach because it arguably violates the "One feature, one OSM element principle": https://www.openstreetmap.org/changeset/126035627 Ignoring the principle (which is not absolute anyway) in this case and adding a relation of type=site + tourism=camp_site containing the actual tourism=camp_site object as a member does solve the problem thus I would go for doing just this as I did a year ago. Obviously others seem to differ here. Currently the above changeset breaks my map regarding those campsites where the tourism=camp_site tag has been removed from the site relation. External features are no longer shown :( So how to resolve this problem? campsites with external features (e.g. sanitary facilities used by a campsite and a sport-center) do exist in the wild and they usually do also have on-the-ground objects (way, node, polygon-relation) where no other tag than tourism=camp_site does make sense. What do you think? Sven ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Defining the meaning of capacity tag for tourism=camp_site
Martin Koppenhoefer wrote: > the typical size of a RV may be regionally different Jepp. In Europe an average camping trailer is usually roughly the same as an average recreational vehicle. Sven -- "Thinking of using NT for your critical apps? Isn't there enough suffering in the world?" (Advertisement of Sun Microsystems in Wall Street Journal) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Defining the meaning of capacity tag for tourism=camp_site
Jan Michel wrote: > In fact, capacity:caravan and capacity:motorhome are used more often > compared to caravans and motorhomes. > > I would go for > > - capacity:persons > - capacity:tents > - capacity:caravan > - capacity:motorhome We are already using plural when tagging caravans=yes/no and tents=yes/no. Thus I would not suggents to tag this singular in case of capacity. Looking at the current state of tagging in taginfo we have: capacity:caravans 65 capacity:caravan 4 capacity:tents 241 capacity:tent 0 Thus I do not see a real argument for using singular here. Sven -- "Thinking of using NT for your critical apps? Isn't there enough suffering in the world?" (Advertisement of Sun Microsystems in Wall Street Journal) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Defining the meaning of capacity tag for tourism=camp_site
Martin Koppenhoefer wrote: >> On 31. Oct 2020, at 11:27, Sven Geggus wrote: >> >> Similar in spirit would be deprecating "maxtents" unsing "capacity:tents", >> "capacity:caravans" and "capacity:visitors" in future. >> >> What do you think? > > prefer this version I just saw, that capacity:persons is already in wide use thus I propose the following: * deprecate maxtents (currently used 1188 times) * urge people to not use plain capacity anymore * Instead the following tags should be used in future: - capacity:persons - capacity:tents - capacity:caravans Regards Sven -- "Thinking of using NT for your critical apps? Isn't there enough suffering in the world?" (Advertisement of Sun Microsystems in Wall Street Journal) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Defining the meaning of capacity tag for tourism=camp_site
Hello, I already have a diary entry for this issue, but I think it would be better discussing it here. https://www.openstreetmap.org/user/giggls/diary/394619#comment48493 The problem is, that real-world usage of the capacity tag on camp-istes is currently inconsistent and thus mostly useless. While the wiki clearly states that capacity means people a lot of mappers seem to think that the number of camp-pitches is meant. The problem is, that both numbers seem to make sense on different types of camp-sites. While the (maximum) Number of people is interesting on group-only, scout and backcountry sites, there is no such thing on camping/caravaning sites at all. In the latter case we are typically talking about the maximum number of tents and caravans while the number of people using the site is usually not limited. As a response to my diary Entry Lyx suggestest two new tags: We already have "maxtents" and we could simply add "maxcaravans" and "maxvisitors" deprecating capacity in case of camp-sites. Similar in spirit would be deprecating "maxtents" unsing "capacity:tents", "capacity:caravans" and "capacity:visitors" in future. What do you think? Sven -- "If you don't make lower-resolution mapping data publicly available, there will be people with their cars and GPS devices, driving around with their laptops" (Tim Berners-Lee predicting Openstreetmap) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - (Unifying playground equipment tagging)
Sören Reinecke via Tagging wrote: > Proposal: > I propose the key playground to be deprecated and the use of key > playground:* instead. That would mean that on both playground and > playground equipment objects in OSM the key playground:* applies. This > then would also allow to map playgrounds and their equipment in > situations where a playground just has one equipment and this equipment > fills up the whole area of the playground. I do not like the idea of pseudo namespacing signle keys at all. I would even go further to say that I generally prefer generic keys over special ones. We already had this discussion in tourism=camp_pitch vs. camp_site=camp_pitch. Using the former instead of the latter will make live easier for database imports. Thus your proposal will make imports even more complicated as it will need wildcard processing for keys like this: "import all objects tagged playgroud:" instead of just "import all objects tagged playground". Regards Sven -- "Thinking of using NT for your critical apps? Isn't there enough suffering in the world?" (Advertisement of Sun Microsystems in Wall Street Journal) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - (Phone)
Valor Naram wrote: > It's awful that we have two tags for the same puropose in our database and > that makes it more difficult for developers and researchers to work with > our data. I fully agree with this. In opencampingmap POI database I currently do a replacement of the following tags during database import: booking -> reservation contact:phone -> phone contact:fax -> fax contact:website -> website contact:email -> email url -> website Would be nice to get rid of stuff like this. Sven -- "In the land of the brave and the free, we defend our freedom with the GNU GPL" (Richard M. Stallman on www.gnu.org) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Campsite properties
Joseph Eisenberg wrote: > (While I wouldn't have picked the key "permanent_camping" myself if > it's only on a seasonal or annual basis, I think it's probably fine, > and I can't think of a better English term.) I can not talk for other countries, but in Germany this setting is definitely *permanent* in a way that people typically have their caravans on the same pitch for years. Its only the fee which is charged on a seasonal or annual basis. Sven -- "Thinking of using NT for your critical apps? Isn't there enough suffering in the world?" (Advertisement of Sun Microsystems in Wall Street Journal) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Campsite properties
Joseph Eisenberg wrote: > That's an interesting idea. I don't know much about this concept > myself, so it would be better if this were kept separate. Is it like > renting a summer cabin, or more like having a permanent spot in a > mobile home park (eg for fixed caravans)? No this is all about renting a pitch for your own caravan not for renting a whole caravan. We already have static_caravans=yes for the latter. > I see it's already been used 50 times. Maybe you can make a proposal > or a wiki page to document it? > https://wiki.openstreetmap.org/w/index.php?title=Key:permanent_camping&action=edit OK, added this page. https://wiki.openstreetmap.org/wiki/Key:permanent_camping Is it allowed to add images from Wikipedia to OSM-Wiki? If so, there would be: https://commons.wikimedia.org/wiki/File:Dauercamper_Asel_Sued_Edersee_20101024.JPG Regards Sven -- The laws of mathematics are very commendable but the only law that applies in Australia is the law of Australia. (Australian prime minister Malcom Turnbull) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Campsite properties
Hello, first of all, as the author of http://opencampingmap.org I basically support any approach to streamline the tagging of campsites! However, I would also like to point out, that the main problem we currently have with campsite mapping in OSM ist not _inaccurate_ tagging but _no_ additional tagging at all! About one third of the sites do not even have a name and another third have a name tag as the only additional one. This will add up to about 60% of sites whith incomplete tagging. Just have a look at the "Campsites with incomplete tagging" site I made up using Osmoscope: http://osmoscope.openstreetmap.de/#map=4/4.85321/40.84314&l=https://camping.openstreetmap.de/osmoscope/incomplete-campsites.json Joseph Eisenberg wrote: > It's been a week since the RFC for this proposal focused on campsites > and related tourism features. It which would: Well not all Users of Openstreetmap-data are regular followers of the tagging list. Don't you think, that known users of stuff you are discussing should be included in such a discussion? I just came about this one reading weekly OSM news and I think that I am certainly one of the known users in case of this stuff. > It which would: > > 1) Deprecate booking=* (use reservation=* instead) I am usually not a friend of such discussions. I just tend to enforce streamlining tagging by using one tag but not another. "booking" is currently not honored in Open Camping Map because it is barely used, so yes, if you like to get rid of it in a somewhat official way I would not object. Another (IMO) mess which comes to mind ist this regard ist the "contact:" prefix bullshit which made me include a tag-mapping feature anyway. So with the current code handling booking in the same way as reservation would be easy to do. > 2) Deprecate bbq=* (use barbecue_grill=* instead). Well, in practice according to taginfo there are zero campsites featuring an additional bbq or barbecue_grill tag. What we often have is an amenity=bbq feature somewhere on the site, which I honor on my map. So frankly I do not care about this one that much as it is currently not in use anyway and thus not supported. > 3) Create new wiki pages: > amenity=greywater_drain > amenity=power_supply > amenity=bear_box > waste_disposal=yes/no > bear_box=yes/no > greywater_drain=yes/no I do not currently support these. However, it might be a good idea to treat an amenity=power_supply on the premises the same as power_supply=yes on the site-object. Is there a difference between a greywater_drain and a sanitary_dump_station? > scout=yes/no In the context of my map I currently treat scout=yes the same as "group_only=yes". These are sites for groups (likely private) after all, regardless of the type of group. > And add new values to these pages: > Key:parking - add parking=yes/no > Key:capacity=* - capacity:tents/caravans/static_caravans would be mentioned Yeah well probably capacity should be specified more clearly. In practice this is even more complicated as some people think of capacity in terms of people rather than tents or caravans. I currently prefer using maxtents as this is more well-defined. > That's a lot of changes. So if anyone dislikes one of these changes, > please say so, so that I can separate it out into it's own proposal. Well if you are about additional tags I would strongly recomend adding another one which is already supported in http://opencampingmap.org In Germany there are a lot of campsites which rent pitches on a seasonal or even yearly base. People often use them as a kind of weekend home. We call them "Dauercamper" which is likely called "permanent campers" in english. As this is quite common here and there are even sites for permanent residents _only_ I invented a tag called permanent_camping=yes/no/only Regards Sven P.S.: You may also have a look at my Open Camping Map Announcement http://blog.gegg.us/2019/01/announcing-open-camping-map/ -- "Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say." (Edward Snowden) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Camp_site=camp_pitch
Joseph Eisenberg wrote: > I still think it's easiest for us to approve the fairly popular tag > "camp_site=camp_pitch", which is already supported by some editors, > since the alternatives also have some disadvantages. +1 -- Das Internet ist kein rechtsfreier Raum, das Internet ist aber auch kein bürgerrechtsfreier Raum. (Wolfgang Wieland Bündnis 90/Die Grünen) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Camp_site=camp_pitch
Tobias Wrede wrote: > So why not tourism=camp_pitch within tourism=camp_site by the same logic? Mainly because the other type of tagging is the already established one and there is no good reason for changing this. The fact, that campsites with one pitch are not taggable is something I would consider a minor issue. Sven -- /* * Wirzenius wrote this portably, Torvalds fucked it up :-) */(taken from /usr/src/linux/lib/vsprintf.c) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Camp_site=camp_pitch
Martin Koppenhoefer wrote: > +1, btw, there are already 226 of these: > https://taginfo.openstreetmap.org/tags/tourism=camp_pitch I object using a generic key like tourism for something this specific as sub-features of a camp site. Although the existing ones do look like miss-tagged camp_site=camp_pitch. Your suggestion would not allow for tagging a site like this: tourism=camp_site camp_site=camp_pitch which would make sense, as single pitch camp-sites _do_ exist. Very simular beasts are individual plots within allotments and these are tagged alike camp_site=camp_pitch: landuse=allotments allotments=plot Sven -- "If you don't make lower-resolution mapping data publicly available, there will be people with their cars and GPS devices, driving around with their laptops" (Tim Berners-Lee) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Camp_site=camp_pitch
Martin Koppenhoefer wrote: > I would not say it is used frequently, we have 100.000 camp sites tagged, > and only 7000 pitches with this tag Given the fact, that about half of them do not have more tags than name (about a quarter lack even name) this ratio is not all that bad. Regards Sven -- .. this message has been created using an outdated OS (UNIX-like) with an outdated mail- or newsreader (text-only) :-P /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Camp_site=camp_pitch
Martin Koppenhoefer wrote: > I’m fine with mapping individual pitches, but I don’t like the key. > “camp_site=*” sounds like a tag for the subtype of a camp site rather than > a different feature within such a site. Unfortunately its currently used for both. https://wiki.openstreetmap.org/wiki/Key:camp_site Not particular nice, but not that bad either. Changing this tag to something else would need automatic editing of 6941 objects. As I already said that I object the camp_pitch prefixing for subtags. Looking at them I also suggest to use the already established tags "power_supply" and "fireplace" instead of "camp_pitch:fire" and "camp_pitch:electric". Regards Sven -- Um Kontrolle Ihres Kontos wiederzugewinnen, klicken Sie bitte auf das Verbindungsgebrüll. (aus einer Ebay fishing Mail) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Camp_site=camp_pitch
Joseph Eisenberg wrote: > It sounds like your sites are used as second homes or vacation homes > in the countryside, so I can see how that could still fit under > tourism=caravan_site. Exactly. However an access=private or access=members might be sufficient as well. Sven -- "Dynamische IP-Nummern sind Security-Homöopathie." (Kristian Köhntopp) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Camp_site=camp_pitch
Joseph Eisenberg wrote: > I'm not sure if direction is necessary. How would the direction tag be used? Direction would be like with benches. > If the pitch has a clear rectangular shape it could be mapped as an > area. Shure, if it can be copied from an aerial image but if its a wooden platform inside a forest all you can aquire then is width, length and direction. https://wiki.openstreetmap.org/wiki/Key:direction Still importatnt to see if its big enough for your tent. > But many tent pitches do not have clearly verifiable boundaries; > these should be mapped as nodes. Right, if they are right on the ground. I have two examples of the former and the latter from backcountry campsites in the black forest: https://www.openstreetmap.org/node/5001823515 https://www.openstreetmap.org/node/4935721966 Image of wooden Platform: https://naturparkschwarzwald.blog/wp-content/uploads/2019/02/Camp-Erdbeerloch.jpg Sven -- "Remember, democracy never lasts long. It soon wastes itself, exhausts and murders itself. There never was a democracy yet that did not commit suicide." (John Quincy Adams) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Camp_site=camp_pitch
Joseph Eisenberg wrote: > I assume these are caravan or motorhome sites? Yep mostly caravans with wheels removed and awnings. > But I think that a place with "permanent_camping=only" is mistagged. Hm basically these are members-only sites without reception but still campsites at least in legal terms. > There is a tag "building=static_caravan" (based on British English) > for motorhomes / trailers / caravans and mobile homes which are used > as permanent residences in one place, year-round. Which does not fit, as theses caravans+awnings still need to be movable at least in theory to stay legal. Theses sites are still somehwat tourism as they are usually used like weekend houses. > We have many "mobile home parks" in the USA which are intended for > year-road habitation, and most of the "vehicles" are up on jacks. Many > have decks and porches built on. I believe these are mapped as > landuse=residential areas, with building=static_caravan for each home. Hm, might be similar, hard to tell. Sven -- Freiheit ist immer die Freiheit des Andersdenkenden (Rosa Luxemburg) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Camp_site=camp_pitch
Hello again, forgot another one. At least here in Germany most campsites have different pitches for short term or long term campers. While the former ones usually stay for a few days or weeks only, the latter ones are more or less permanent residents which pay on a seasonal base rather than a daily one. I already invented a "permanent_camping"="yes","no","only" tagging for tourism=camp_site which is rendered in http://opencampingmap.org, but these are usually separated pitches on campsites which offer both. An example for such a map with different kinds of pitches is here: https://www.st.leoner-see.de/_Resources/Persistent/9edfc4f633cfdde20abd8744cdba220af0564f1d/St.Leoner_See_Plan_03_2019.pdf Individual pitches are not mapped in OSM on this site: https://opencampingmap.org/#12/49.2773/8.5546/0/0/bef/way/56323471 Regards Sven -- "If you don't make lower-resolution mapping data publicly available, there will be people with their cars and GPS devices, driving around with their laptops" (Tim Berners-Lee) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Camp_site=camp_pitch
Joseph Eisenberg wrote: > Please comment here or on the proposal discussion page: > https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/camp_site_pitch Looks good, by and large :) Any reason for using a "camp_pitch:" prefix/namespace instead of generic tagging? A surface is just a surface after all and the information, that it is the surface of a camp_pitch is already given by the camp_site=camp_pitch tagging. So prefixing is redundant at best. In practice this stuff will only lead to some kind of unificatiopn step when processing data. Frankly, I would prefer using generic tags. I already ran into this problem when dealing with website vs. contact:website where I had to implement a special handling for this stuff. Looking at the additional tags I would also suggest to add the following for nodes: * width * length * direction Rationale for this is, that at least here in Germany there are wooden pitches in some backcountry campsites where this information might be very useful. See http://www.naturpark-eifel.de/de/projekte/detail/Eifel-Trekking-32o/ for an image of such a beast. Regards Sven -- Author of http://opencampingmap.org ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging of Country Names
Andy Townsend wrote: > Straying from the point slightly, but what would be really, really nice > would be a worked example of a way of obtaining wikidata information > as part of map data processing There might be another option. Given a hstore database or wikidata column it would be very easy to build a query_wikidata psql function which will query wikidata like this: select query_wikidata(tags->'wikidata') from planet_osm_point where ...; This would be only a few lines of pl/pgsql wrapper code using pgcurl: https://github.com/Ormod/pgcurl Regards Sven -- "Software is like sex; it's better when it's free" (Linus Torvalds) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging of Country Names
David Bannon wrote: > As a native English speaker, I often turn to OSM to help me understand > some of the global issues around at present. But even now, many of the > place names are rendered in local language, quite unreadable to me. This is true for any westerner. Have a look at the talk I gave at FOSS4G concerning this topic: https://github.com/giggls/mapnik-german-l10n/wiki In the meantime I also made a version with english as a prefered langage for internal use at my workplace: http://tile.iosb.fraunhofer.de/#map=3/16.88/39.5 Regards Sven -- "Thinking of using NT for your critical apps? Isn't there enough suffering in the world?" (Advertisement of Sun Microsystems in Wall Street Journal) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging of Country Names
Andy Townsend wrote: > OK - another googly* for you - what do you think should be in the "name" > tag for India**? Why do you think that I would want to change the current english tag there? As I already wrote in my other Mail: All I want to get rid of is english names in countries where english is not an official or otherwise important langage and the suspicion comes to mind, that the english name has been added to the name for the sole purpose of making it readable in the standard style. Sven -- "Whenever there is a conflict between human rights and property rights, human rights must prevail." (Abraham Lincoln) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging of Country Names
Hello, looks like some people did not understand what I intend to do. My intention is to remove english names in the generic "name" tag in countries where english is neither an official nor otherwise important langage to the country in question. I'm well aware of the political impact of naming in some places. Regards Sven -- "Das ist halt der Unterschied: Unix ist ein Betriebssystem mit Tradition, die anderen sind einfach von sich aus unlogisch." (Anselm Lingnau in de.comp.os.unix.discussion) /me ist giggls@ircnet, http://sven.gegg.us/ im WWW ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging of Country Names
Warin <61sundow...@gmail.com> wrote: > Would any transcription be placed into name:la=* (la is the language code > for Latin)? The place for transcriptions is name:rm_XX which XX beeing somethiong like jp or kr. All I want to achieve is to get more consistency inte the generic name tag. I have not been talking about name:* at all. However following this discussion I came to the conclusion that it would probably be a good idea to invent an official_language tag as "name" seems to be a moving target by its very nature. Regards Sven -- "Thinking of using NT for your critical apps? Isn't there enough suffering in the world?" (Advertisement of Sun Microsystems in Wall Street Journal) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging of Country Names
Kevin Kenny wrote: > Some problems don't have good solutions. The longer I think about this, the more I come to the conclusion, that having an official langage tag as Simon suggested might be the ways to go. This way producers of maps can avoid using "name" at all. Sven -- "Thinking of using NT for your critical apps? Isn't there enough suffering in the world?" (Advertisement of Sun Microsystems in Wall Street Journal) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging of Country Names
Colin Smale wrote: > Are you talking about the "default map", or the underlying data (i.e. > the contents of name and name:xx tags)? Both. As I consider adding an english name in standard name tag as "tagging for the renderer" it is _not_ off-topic here. I hope we agree, that changing the name tag in a way that it appears more readable for westerners on the standard map is not a good idea. Sven -- "We don't know the OS that God uses, but the Vatican uses Linux" (Sister Judith Zoebelein, Vatican Webmaster) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging of Country Names
Andy Townsend wrote: > As has already been said this _ought_ to be a job for wikidata. Thus one would need an additional external database to render a proper map! I don't think that this is the way to go in such a simple case. Frankly I don't care that much about the proper name tag itself, but I don't think that there is a single valid argument for tagging an english or french name in addition to the local one if this langage is not common a particular country. The only argument I could think of here ist tagging for the renderer. As I already said, such stuff is making it very difficult to render a proper localized map. Regards Sven -- "Thinking of using NT for your critical apps? Isn't there enough suffering in the world?" (Advertisement of Sun Microsystems in Wall Street Journal) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging of Country Names
Chris Hill wrote: > How would you propose making this change? I think we should come up whith a common sense rule what name should usually contain (hence this discussion) and thus the tagging can be changed by mappers accordingly. Currently the state is inconsistent (see Egypt vs. Thailand example). I could also live with an "english-name native-name" rule because I could remove the english name automatically for my map. All I want to get rid of is the current inconsistency. Regards Sven -- "Das Einzige wovor wir Angst haben müssen ist die Angst selbst" (Franklin D. Roosevelt) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging of Country Names
Stefano wrote: > If you'd want the name only in official languageS the problem will arise in > countries with more than one (and equally) official language. Not really, I do not consider rendering something like this a bad idea: Algerien (ⵍⵣⵣⴰⵢⴻⵔ الجزائر) Kurrently we have "Algerien (Algérie ⵍⵣⵣⴰⵢⴻⵔ الجزائر)" where I would think that we should definitely remove the french name. I think the best would be to strictly stay with the countries official languages arguably also separating them by dashes. Regards Sven -- "Thinking of using NT for your critical apps? Isn't there enough suffering in the world?" (Advertisement of Sun Microsystems in Wall Street Journal) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Tagging of Country Names
Hello, in our localized German map style we try to render Country names in German with local name in parenthesis. This works fine for a lot of countries. An example would be Thailand: Thailand (ประเทศไทย) or (more readable for westerners) France: Frankreich (France) Unfortunately there are some countries where this will not work: Ägypten (Egypt مصر) So this is where the tagging discussion starts. I consider this a bad example of tagging for the renderer. English is not an official language of Egypt thus the string "Egypt" is simply invalid in the countries name tag. What I consider valid would be the countires name in all of its official langages. Thus the right one would be: Ägypten (مصر) So I propose a correction of all country names to names into official langages of the respective countries only and to remove all english names. Any objectives? Sven -- Um Kontrolle Ihres Kontos wiederzugewinnen, klicken Sie bitte auf das Verbindungsgebrüll. (aus einer Ebay fishing Mail) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
