Re: [Tagging] [Imports] IENC of the German WSV
2013/12/10 Martin Koppenhoefer dieterdre...@gmail.com E.g. seamark:type=harbour is fine for a seamark indicating a harbour, but it isn't (IMHO) a nice tag for the harbour itself. it seems though, that what is currently done is exactly this: add seamark:type=harbour to the whole area of the harbour: https://wiki.openstreetmap.org/wiki/Tag:seamark:type%3Dharbour It also seems odd to add all facilities as attributes to the main object rather than mapping them inside the area at the place where they are (if I understood that page right, the former is what it suggests). E.g. Wi-Fi harbour:wifi Availability of WiFi access point. Drinking Water harbour:water_tap Availability of potable water. Showers harbour:showers Availability/access of shower/bathing facilities. Toilets harbour:toilets Availability/access of toilet facilities. Laundrette harbour:laundrette Availability/access of laundry facilities. why should we use a different tag for a wifi or a toilet because it is inside a harbour? We already have standard tags for those objects, duplicating the information seems strange to me, like a parallel project inside the project. As this seems a general problem with openseamap tags, I suggest to involve also the tagging ML (cc.). This was already mentioned years ago but apparently it didn't change until now. cheeers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [Imports] IENC of the German WSV
On 11/12/2013 09:29, Martin Koppenhoefer wrote: It also seems odd to add all facilities as attributes to the main object rather than mapping them inside the area at the place where they are (if I understood that page right, the former is what it suggests). E.g. It is not rather than, but as well as. The harbour object is tagged with a list of *available* facilities, the tag values being free text to qualify those availabilities. e.g. harbour:toilets could take the value private, access by code. The actual location of these facilities are mapped separately, with appropriate tags, either from the amenity series or from the seamark:small_craft_facility series. The reason for this arrangement is that querying a harbour object will bring up a list similar to those found in marina directories, nautical almanacs, etc. Anyway, this thread is about the import, not the tagging! I know that we all love to argue about tags, but this is best done in the tagging list. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] OpenSeaMap tagging - seamark-prefix was Re: [Imports] IENC of the German WSV
2013/12/11 Malcolm Herring malcolm.herr...@btinternet.com Anyway, this thread is about the import, not the tagging! I know that we all love to argue about tags, but this is best done in the tagging list. welcome back to tagging ML, I agree with zou, hence the tagging cc. The reason for this arrangement is that querying a harbour object will bring up a list similar to those found in marina directories, nautical almanacs, etc. An analogy would be to tag on every city object all streets that make up this city, so you can get a list similar to a street index. ;-) We are working with spatial data, so creating a list like that which you mention can be done (easier and with fewer maintance/consistency issues) by querying for a list of given facilities inside a harbour polygon, really no need to duplicate this information. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] OpenSeaMap tagging - seamark-prefix was Re: [Imports] IENC of the German WSV
OpenSeaMap are trying to make a parallel database inside the same database. They have to merge at some point, and the sooner the better for all. Janko 2013/12/11 Martin Koppenhoefer dieterdre...@gmail.com 2013/12/11 Malcolm Herring malcolm.herr...@btinternet.com Anyway, this thread is about the import, not the tagging! I know that we all love to argue about tags, but this is best done in the tagging list. welcome back to tagging ML, I agree with zou, hence the tagging cc. The reason for this arrangement is that querying a harbour object will bring up a list similar to those found in marina directories, nautical almanacs, etc. An analogy would be to tag on every city object all streets that make up this city, so you can get a list similar to a street index. ;-) We are working with spatial data, so creating a list like that which you mention can be done (easier and with fewer maintance/consistency issues) by querying for a list of given facilities inside a harbour polygon, really no need to duplicate this information. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] OpenSeaMap tagging - seamark-prefix was Re: [Imports] IENC of the German WSV
We (OpenSeaMap) are open to suggestions on this. The harbour project has recently been re-started after a hiatus of several years. As we are building a separate database to contain imports from various public harbour data sources. These harbour objects only require a simple seamark:type=harbour tag to cause our map to render an icon and pop-up data from this database with a mouse hover. The question is: how do OSM mappers contribute to this data? Hence the facility availability tags. (These tags have existed for years, but were rarely used). I would be interested to hear (constructive!) ideas. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [Imports] IENC of the German WSV
On Wed, Dec 11, 2013 at 11:15 AM, Malcolm Herring malcolm.herr...@btinternet.com wrote: Anyway, this thread is about the import, not the tagging! I know that we all love to argue about tags, but this is best done in the tagging list. Yes, what is the best tag for wifi or toilets can be discussed in the tagging list. But doubling tags and elements for the same feature is unwelcome. The argument about simplifying db queries in a possible third party app is not valid. We don't do that for toilets in mall or supermarkets or atm's in banks or cantines in university campus. Why it should be suddently different for harbours ? because the information comes from an import ? Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] OpenSeaMap tagging - seamark-prefix was Re: [Imports] IENC of the German WSV
On Wed, Dec 11, 2013 at 11:56 AM, Malcolm Herring malcolm.herr...@btinternet.com wrote: I would be interested to hear (constructive!) ideas. For instance: toilets. Instead of adding a harbour:toilets=yes/no, your application should check for the existing tag amenity=toilets or toilets=yes/no ([1]) either on the harbour polygon itself or in one element inside this polygon. It's not the first time that OpenSeaMap is duplicating tags just to avoid some software dev. For instance, the whole OpenSeaMap/Harbours wiki ([2]) is doubling what is specified in Harbour ([3]). Even buildings have their own tags/namespace in your system ([4]) with e.g. seamark:building:function and seamark:building:shape. Finally, the seamark namespace has to be interpreted as the openseamap porject domain. You work since years in parallel and with no intention to consolidate with the existing data/practices. Pieren [1] https://wiki.openstreetmap.org/wiki/Toilets [2] https://wiki.openstreetmap.org/wiki/OpenSeaMap/Harbours [3] https://wiki.openstreetmap.org/wiki/Harbour [4] https://wiki.openstreetmap.org/wiki/OpenSeaMap/Buildings ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging Digest, Vol 51, Issue 27
Hi OpenSeaMap! I want to support what Pieren is saying Having started to tag lakes and harbors all around Switzerland, I realized that: 1. The OpenSeaMap tags and OSM tags do not match. 2. Most of the tags are not rendered. This situation is a pity. I do not want to live in two different worlds. So I really suggest that OpenSeaMap uses standard tags where possible, and clearly documentating things. This will very much improve probability that mappers will map and renders will render! Nounours We (OpenSeaMap) are open to suggestions on this. The harbour project has recently been re-started after a hiatus of several years. As we are building a separate database to contain imports from various public harbour data sources. These harbour objects only require a simple seamark:type=harbour tag to cause our map to render an icon and pop-up data from this database with a mouse hover. The question is: how do OSM mappers contribute to this data? Hence the facility availability tags. (These tags have existed for years, but were rarely used). I would be interested to hear (constructive!) ideas. I would be interested to hear (constructive!) ideas. For instance: toilets. Instead of adding a harbour:toilets=yes/no, your application should check for the existing tag amenity=toilets or toilets=yes/no ([1]) either on the harbour polygon itself or in one element inside this polygon. It's not the first time that OpenSeaMap is duplicating tags just to avoid some software dev. For instance, the whole OpenSeaMap/Harbours wiki ([2]) is doubling what is specified in Harbour ([3]). Even buildings have their own tags/namespace in your system ([4]) with e.g. seamark:building:function and seamark:building:shape. Finally, the seamark namespace has to be interpreted as the openseamap porject domain. You work since years in parallel and with no intention to consolidate with the existing data/practices. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - landuse=highway
I am still in favour of this proposal. Yes, we need to better distinguish between area:highway and landuse. One point in favour is the well-used landuse=railway which often includes areas tagged with natural=scrub. Cheers fly On 04.12.2013 21:01, bulwersator wrote: And feedback suddenly appeared. As now people noticed this proposal and first people against appeared voting was suspended to improve proposal. On Wed, 04 Dec 2013 10:35:17 -0800 *bulwersatorbulwersa...@zoho.com* wrote landuse=highway - identifies an area of land on which a highway together with any associated footways and verges are constructed. I started voting on http://wiki.openstreetmap.org/wiki/Proposed_features/highway ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] OpenSeaMap tagging - seamark-prefix was Re: [Imports] IENC of the German WSV
2013/12/11 Pieren pier...@gmail.com On Wed, Dec 11, 2013 at 11:56 AM, Malcolm Herring malcolm.herr...@btinternet.com wrote: I would be interested to hear (constructive!) ideas. ... Finally, the seamark namespace has to be interpreted as the openseamap porject domain. You work since years in parallel and with no intention to consolidate with the existing data/practices. +1 (to all of Pièrre's message), and this is refering apparently to ALL tags. Why use a duplicate tag seamark:harbour if there are landuse=harbour and leisure=marina? Every single tag get duplicated and prefixed with seamark --- regardless whether it is a seamark / sign or something else (as he wrote, basically you have created a Openseamap-namespace inside OSM by prefixing seamark to everything). A constructive suggestion is to try to consolidate your tags. Use the seamark-prefix ONLY for seamarks and use OSM tags for stuff that already has established tags. There might be some grey areas (e.g. a landmark might not be a landmark if viewed from sea), but these are rare edge cases (and we'll surely find a solution) while you have literally invented duplicate tags for everything from toilets to restaurants. And bridges. And military areas. And... Rather than inventing a new tag for every object in the S-100 catalogue you should look what of these is already covered with standard osm tags and modify your editor presets accordingly. cheers, Martin https://wiki.openstreetmap.org/wiki/Tag%3Aseamark%3Atype%3Dbridge ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - landuse=highway
2013/12/11 fly lowfligh...@googlemail.com I am still in favour of this proposal. Yes, we need to better distinguish between area:highway and landuse. I don't see the problem. The only reason that the strange and un-traditional tag area:highway was introduced was to avoid confusion with the legal road (landuse). We are already tagging similarly for railways (landuse=railway). Where are the open questions? cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - landuse=highway
On 11.12.2013 15:52, Martin Koppenhoefer wrote: 2013/12/11 fly lowfligh...@googlemail.com mailto:lowfligh...@googlemail.com I am still in favour of this proposal. Yes, we need to better distinguish between area:highway and landuse. I don't see the problem. The only reason that the strange and un-traditional tag area:highway was introduced was to avoid confusion with the legal road (landuse). We are already tagging similarly for railways (landuse=railway). Where are the open questions? I do not have any questions but the proposal does not even mention area:highway=* and is talking about landuse=grass which should be avoided, anyway. All along this is one more example of the lately used practice to start voting after a few weeks with not well designed proposals (useful tags but missing links, missing pictures, missing differentions etc.). At least it seems to lead to more discussion about the issues. cu fly ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Topographic place names
On Tue, Dec 10, 2013 at 10:50 PM, Martin Koppenhoefer dieterdre...@gmail.com wrote: the question should be: how to map a mountain range, as it seems we can't represent these kind of features (very big, blurry borders, not mappable in high zoom levels) well in our data model. That's the main reason why we don't have these. There are also other features similar to a mountain range (a forest as name for a region, including non-forest areas, lowlands / plains, desert, ...). Actually we don't have tags or a way to map to most of these geographic features and regions besides the atomic components (like peaks). Thanks, I was having trouble articulating what the issue is. Tags like landuse=* or natural=* often work well for mapping a physical property with a sharp border - but not so well when we're describing a human abstraction (a mountain range is really an abstraction over a number of individual mountains, and it's up to some sort of geologists' consensus where it begins and ends). IMHO it would be nice to have an alternative dataset in lower zoomlevels for geographic regions and extended/blurry features, something like a set of shapefiles with translations into all languages we can provide, something similar to what natural earth data provides, but distributed and modified/translated by us, not just English and for higher zoom levels (i.e. more detailed) than what NE has. Still we could start with their geographic regions dataset and refine it, as All versions of *Natural Earth* raster + vector map data found on this website are in the public domain. Are you saying that this kind of data is a poor fit for OSM itself? if you don't know what it is (i.e. generic feature) place=locality seems perfectly fitting, otherwise be more precise and tag or subtag it as what it is (e.g. a cluster of rocks). My issue with place=locality is that the place=* are basically for human habitation, whereas these can occur in completely uninhabited places. As a cartographer, I'd want to label these using topographic styling (ie, similar to how I'd show natural=peak, natural=saddle), and not at all similar to place=hamlet Hence my desire for something like natural=feature - a catch-all, label any natural feature. Steve ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Topographic place names
On Tue, Dec 10, 2013 at 10:03 PM, Andrew Errington erringt...@gmail.comwrote: On Tue, 10 Dec 2013 19:26:55 Steve Bennett wrote:Yes please! I just added some hiking trails and had a named spur[1] that I wanted to record. I used place=locality, but it seems wrong for the same reasons you give. I'd suggest that since we have natural=peak, and natural=saddle we should have natural=spur. natural=ridge, if it's not already used, should be for ridges. natural=ridge is widely used (~8000) for ridges: http://taginfo.openstreetmap.org/tags/natural=ridge There's also natural=arrete (273): http://taginfo.openstreetmap.org/tags/natural=arete Remarkably, there is not a single use of natural=spur. Maybe people just tag them as ridges? Could use natural=ridge, ridge=spur to be more precise perhaps. Perhaps we could also have natural=feature for a general named 'thing' that is visible and well known. 174 examples already: http://taginfo.openstreetmap.org/tags/natural=feature#overview Taginfo doesn't seem to show any other information on them - I'd like to see how else they're being used. Steve ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
