Re: [Tagging] Barrier=berm
The proposal looks good to me. Thanks for your effort. On Tue, Nov 26, 2019 at 9:51 AM Graeme Fitzpatrick wrote: > Following the recent discussions of protective walls, I've created a page > for barrier=berm https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dberm > > As it is already in use 61 times, I didn't think we had to go through the > full RFC / voting procedure, but please correct me if I'm wrong? > > As always, comments & discussion welcomed! :-) > > Thanks > > Graeme > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging estuaries: estuary=yes or river=estuary?
I live in Alaska and the tidal range there is huge, 28 feet (8.5 meters) with the spring high tides. Also, Alaskan rivers are usually so remote that one has no good way to even estimate how far the high tide extends upriver. On Sat, Oct 26, 2019 at 6:25 PM Iago Casabiell wrote: > This is a very complicated subject, made even more compliclated because > the coastline is only mapped in high tide. Intertidal zones are huge. > There's a proposed tag to map the low tide coast: > natural=mean_low_water_springs. > ( > https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:natural%3Dmean_low_water_springs > ) > > I think a key for a generic term for a river mouth is needed, extending > beyond natural=coastline, wich should reach upriver to where the high tide > crawls. > Also there should be a specific tag for each type of river mouth: estuary, > fjord, ría, delta, etc. > > I live in Galicia in NW Spain where the tidal range is above 4m and tiny > rivers open into huge well defined bays called rías. I've been mapping them > as bays in these last few months and there is still much work to do > extending natural=coastline upriver, drawing natural=mean_low_water_springs > and defining each type of natural=wetland contained in the ría. Check it > out and you'll see it's complicated, and also see why this new tagging is > very important. > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging estuaries: estuary=yes or river=estuary?
Hi Clifford, Can you help me find something in the Skagit Delta that is tagged with the estuary tag? When I read your post, I immediately tried to check it out because I'm trying to understand how that tag is being used currently. But I wasn't able to find anything. Thanks for your help. On Sat, Oct 26, 2019 at 9:29 AM Clifford Snow wrote: > Looking at the US NHD estuary is broadly defined. For example, The Skagit > River flows through my county into the Puget Sound in Washington State. I > would expect the delta area, where it empties into the sound to be defined > as an estuary. And it is. But apparently so is the whole of Puget Sound. > The trouble I see if 1) if we define an estuary different than scientific > model or 2) use the science definition of an estuary. If we differ from the > science definition, we'll constantly battle users of what is included in > our model and what isn't. If we go with the scientific definition then > we'll get questions on why we picked that model when it sometimes doesn't > make sense. > > I'd really like to hear from someone that can explain exactly what an > estuary encompases and what makes sense to map. > > Best, > Clifford > > On Fri, Oct 25, 2019 at 5:26 PM Dave Swarthout > wrote: > >> Then there is the additional problem that the terminal end of the way >> used to indicate the waterway=river connects with the "coastline" which is >> where the estuary portion of the river ends. I'm not clear about which >> object you propose adding the estuary=yes tag to? Let me put it another >> way. If the particular river is mapped using a way that terminates on the >> coastline, where does the estuary tag get placed? I realize that some >> rivers are mapped using just a riverbank area, i.e, there is no way to >> terminate, but that still leaves my question unanswered. >> >> On Sat, Oct 26, 2019 at 7:13 AM Graeme Fitzpatrick >> wrote: >> >>> & we get back to the same problem previously discussed with river > sea >>> ... >>> >>> At what point does a river become an estuary & where does that then >>> become the sea? >>> >>> Having said that, I quite like river=estuary :-), but I think we'll have >>> problems defining it? >>> >>> Thanks >>> >>> Graeme >>> >>> >>> On Sat, 26 Oct 2019 at 09:53, Paul Allen wrote: >>> >>>> On Sat, 26 Oct 2019 at 00:43, Warin <61sundow...@gmail.com> wrote: >>>> >>>>> >>>>> estuary = tidal mount of a large river? As defined by the Oxford >>>>> Dictionary. >>>>> >>>> >>>> Estuaries are complicated. https://en.wikipedia.org/wiki/Estuary >>>> >>>> -- >>>> Paul >>>> >>>> ___ >>>> Tagging mailing list >>>> Tagging@openstreetmap.org >>>> https://lists.openstreetmap.org/listinfo/tagging >>>> >>> ___ >>> Tagging mailing list >>> Tagging@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/tagging >>> >> >> >> -- >> Dave Swarthout >> Homer, Alaska >> Chiang Mai, Thailand >> Travel Blog at http://dswarthout.blogspot.com >> ___ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > > > -- > @osm_washington > www.snowandsnow.us > OpenStreetMap: Maps with a human touch > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging estuaries: estuary=yes or river=estuary?
Then there is the additional problem that the terminal end of the way used to indicate the waterway=river connects with the "coastline" which is where the estuary portion of the river ends. I'm not clear about which object you propose adding the estuary=yes tag to? Let me put it another way. If the particular river is mapped using a way that terminates on the coastline, where does the estuary tag get placed? I realize that some rivers are mapped using just a riverbank area, i.e, there is no way to terminate, but that still leaves my question unanswered. On Sat, Oct 26, 2019 at 7:13 AM Graeme Fitzpatrick wrote: > & we get back to the same problem previously discussed with river > sea ... > > At what point does a river become an estuary & where does that then become > the sea? > > Having said that, I quite like river=estuary :-), but I think we'll have > problems defining it? > > Thanks > > Graeme > > > On Sat, 26 Oct 2019 at 09:53, Paul Allen wrote: > >> On Sat, 26 Oct 2019 at 00:43, Warin <61sundow...@gmail.com> wrote: >> >>> >>> estuary = tidal mount of a large river? As defined by the Oxford >>> Dictionary. >>> >> >> Estuaries are complicated. https://en.wikipedia.org/wiki/Estuary >> >> -- >> Paul >> >> ___ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Divided highways, and not so divided highways, one way or two
Asking OSM mappers if they have "strict standards" on this issue is chasing a fantasy, IMHO. We discussed this in our local Thailand mapping forum and AFAIK, it wasn't resolved. In one example, a five-lane highway with no physical barrier and the "fifth lane" painted with big yellow stripes, the mapper used two separate ways, both tagged oneway=yes to represent the situation. I disagreed. My thinking is that OSM prefers having a physical barrier before tagging two separate ways and I do too. By the way, Google maps uses two lanes both tagged as oneway for this particular example. YMMV On Thu, Oct 10, 2019 at 1:40 PM Frederik Ramm wrote: > Hi, > > DWG has been asked to mediate in a user dispute in Germany where a local > mapper has chosen to represent a busy four-lane primary highway (two > lanes in each direction, and a double continuous line painted in the > middle which is physically possible but legally not allowed to cross). > > Other mappers object to this saying that it violates the rule that there > must be some sort of physical division to allow that form of mapping. > > The original mapper claims that using two separate oneway=yes ways is > clearer and easier, as it does away with the need for turn restrictions > at junctions. Other mappers claim that the two-separate-way mapping is > violating rules and that OSM will soon become unusable if everyone maps > how they want. > > The question is basically two-fold; one, what are the established > standards and rules concerning this situation, and two, in how far is it > acceptable to deviate from these standards if a local mapper thinks it > is a good idea. > > Personally I believe that "physical division => separate ways; no > physical division => shared way" is the standard in OSM, or perhaps at > least the "rule of thumb". But (since people in the German discussion > have more or less claimed that the world is going to end if local > mappers are allowed to treat this differently) I'd like to hear from > mappers in other countries how rigidly this standard is applied. Is it > something where local mappers have some freedom of judgment (like when > choosing which highway=* category to apply to a road) or do you have > strict standards and definitions? > > Bye > Frederik > > -- > Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New tag proposal: 'addr=milestone'
The "milestone" value is a misnomer in most modern situations. Here in Thailand, many roads have actual mile markers, er kilometer markers, but they are not made of stone. They are painted concrete. In the U.S. there are very few of these if any. When I'm tagging mile markers in the U.S., I include a tag description=Metal flag One of the things I love to map in Thailand are km=0 milestones which denote the beginning of a numbered route. To date, I've added approximately 270 of these special milestones. On Wed, Oct 2, 2019 at 12:43 AM Aaron Young wrote: > What I'm unclear on is if these addresses refer to an actual road > marker, or an actual distance based upon interpolation between > actual road markers. If you have a road marker at 8km and another > road marker at 9km, would a house between the two have addr:milestone > 8, 9 or 8.5? If the address is of an actual road marker then addr:milestone > would be appropriate (given that we already misuse highway=milestone > to mean kilometre markers); if it's a distance that doesn't correspond to > an actual road marker then we need a better name. > > I would expect the address:milestone=8.5 would be used. This is something > that can be determined by software and is not always written on signage but > widely used. > > There are also usages within the US for emergency response purposes. > Highway call boxes often use mile marker or milestone reference to > determine location of incident. US highways have milemarker signage every > mile to assist with this purpose. Utilizing it in address finding > throughout the world is a needed tag in my opinion. > > Aaron > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New tag proposal: 'addr=milestone'
> I may be mistaken but I seem to remember mile markers being used in rural areas of the USA to indicate linear position along a main road. You are not mistaken. Many hotels and parks in the rural areas of Alaska mark their location that way. On Tue, Oct 1, 2019 at 2:06 PM Colin Smale wrote: > On 2019-10-01 08:18, Florian Lohoff wrote: > > Hi Jorge, > > On Mon, Sep 30, 2019 at 08:15:37PM -0600, Jorge Aguirre wrote: > > Throughouthe entire Latin American region and some other parts of > the world, it is quite common to find the kilometer (Km.) information, > as may be found on the "highway:milestone", as part of the actual > addresses. Mostly used in suburban and rural areas, which may usually > not even have any visible references or even house numbers, the use of > the milestone is widely utilized to find an address in these regions. > > > We have such addresses in Germany too. They are pretty rare though. > sometimes really rural mobile masts or copper distribution > street cabinets and stuff carry addresses like this. > > I may be mistaken but I seem to remember mile markers being used in rural > areas of the USA to indicate linear position along a main road. > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Strange tags
Yes, it's always complicated, isn't it? I realize many folks are interested in climbing all the peaks on certain lists. Good for them. The Adirondack 46ers was the only one familiar to me. As I said, I have no stake in this. It was mostly curiosity that motivated me to bring it to the Tagging group. On Mon, Sep 30, 2019 at 8:40 AM Kevin Kenny wrote: > On Sun, Sep 29, 2019 at 7:51 PM Dave Swarthout > wrote: > > > > Well, I'll be damned. These hikers, or "hillbaggers", are using these > tags for their own purposes. Many of them could easily be derived from the > ele tag. I have no stake in whether they do that or not except to say that > it encourages others to make up tags for their own regional uses. In New > York State there is a list of 46 peaks that top 4,000 feet and anyone who > summits them joins the group called "The 46ers." But nobody maps them with > 46er=yes/no because this information is immediately obvious from the ele > tag. > > Actually, it's the list of peaks that were thought to be above 4000 > feet (and with requirements for prominence and isolation) at the time > that the club was founded. Simple elevation is not enough to determine > this. Because of prominence and isolation requirements, Pyramid Peak > (4597 ft AMSL) is not on the list; it is considered to be a subsidiary > summit of Gothics. Similarly, Little Marcy and Schofield Cobble are > considered subsidiary summits of Mount Marcy, but Gray Peak squeaks in > with just barely the required prominence. Moreover, it turns out in > modern surveys that Mount Blake, Cliff Mountain, Nye Mountain and > Couchsachraga are all less than 4000 feet AMSL, while MacNaughton > Mountain tops 4000 feet but is not one of the 46. Finally, Slide > Mountain (4120 feet) and Hunter Mountain (4040 feet) are excluded by > being outside the Adirondack Park - they are both clearly above 4000 > feet and have tremendous prominence, but they're in an entirely > different range. > > The Catskill 35 (which has Slide and Hunter as its two tallest peaks) > are another list that's locally significant. It purports to be the "35 > summits above 3500 feet in the Catskills" but once again that's an > oversimplification. For it, the prominence and isolation rules have > been fine-tuned over the years to keep the list stable. "The Dink", > south of Cornell Mountain, "Camel's Hump" west of Thomas Cole > Mountain, or "Little Slide" north of Slide Mountain all are > unquestionably named peaks above 3500 feet, but either are not > prominent enough or are too close to a different peak. The definitions > have to be tuned very finely, however, to keep Wittenberg from being > considered a subsidiary summit of Cornell Mountain. Since the club's > founding, only one peak has been added to the list: its name is > Southwest Hunter, or Leavitt Peak, or Hill 3750, depending on what > version of the list you consult. It was nameless until its inclusion > on the list meant that hikers needed a name for it. (Grace Peak in the > Adirondacks has a somewhat similar story, and did indeed acquire a > name from being listed.) The current feeling in the club appears to be > that the list should now be fixed as it stands. If it turns out, as is > plausible, that the high point of Dry Brook Ridge or Millbrook Ridge > tops out above 3500 feet, the sentiment appears to be that they should > not be added. > > The Catskill 35 list also contains four summits (Slide, Blackhead, > Balsam [Ulster County] and Panther) that have to be climbed twice - at > least once in winter. The choice of which summits were included in > that list appears to have been entirely arbitrary, and the club > founders never offered an explanation. > > Given that the lists at this point are arbitrary, there's really no > way to represent the list membership other than making up some > entirely arbitrary scheme. If asked to come up with something, I'd > probably put the 46 summits in a group relation and hang the name > 'Adirondack 46' off that. I'd do a similar thing for the Catskill 35, > but then scratch my head about how to identify the Winter Four. > > As it is, I use information external to OSM for rendering this area so > that the list memberships can be shown - they are quite important to > the local hikers, many of whom are chasing their Adirondack 46'er or > Catskill 3500 Club badges. Peak-bagging is a serious sport around > here! > > I've not tried to add the information because I eschew controversy. I > know that on the 'tagging' list there are hard-liners who would even > challenge adding the peaks' names to the list, on the grounds that the > names for the most part cannot be observed in the field. (Look at a > topo ma
Re: [Tagging] Strange tags
Well, I'll be damned. These hikers, or "hillbaggers", are using these tags for their own purposes. Many of them could easily be derived from the ele tag. I have no stake in whether they do that or not except to say that it encourages others to make up tags for their own regional uses. In New York State there is a list of 46 peaks that top 4,000 feet and anyone who summits them joins the group called "The 46ers." But nobody maps them with 46er=yes/no because this information is immediately obvious from the ele tag. In Thailand, there are local expat mappers who "name" a track or path in rural regions "Single-track" or "Double track" thus indicating in their own way whether it's suitable for motorcycle use. I try to discourage such mapping, preferring to address it some other more uniform and acceptable manner. This usage amounts to the same thing in IMO. I mean, the list in the Wikipedia article is a long one. Do we really want all this extra, what I would term, clutter? I'm not suggesting removing those tags but was just curious about them. On Mon, Sep 30, 2019 at 2:39 AM Valor Naram wrote: > But as datauser I won't use that data. We need to find a way to make the > tags more useful in global scope. That can be done by translating to widely > supported tags etc. > > ~ Sören Reinecke alias Valor Naram > > > Original Message > Subject: Re: [Tagging] Strange tags > From: ael > To: tagging@openstreetmap.org > CC: > > > On Sun, Sep 29, 2019 at 07:24:16PM +0200, Jan Michel wrote: > > On 29.09.19 17:07, Paul Allen wrote: > > > > > > Really? > > > > > > There are people who are VERY interested in these things. People who > > > want to know where > > > Munros, Donalds, Grahams, Marilyns, TuMPs, etc. are. > > > > Well... There is no documentation of these tags in the OSM wiki. > > While that is certainly desirable, it is not necessary, especially where > the terms are well known - at least in the relevant region. > > > > > These seem to be very local terms that are not used outside of Scotland > > (British Isles?). In general we oppose such local terms as keys because > they > > won't be of any use outside a small area. > > Who are "we" who oppose such terms? > > OSM is trying to be the best map possible, and the map should be useful > in small areas (like the UK) as well as more globally. > > Even if one local mapper with special local knowledge tags something > only understood in a very small area, it is still improving the map. > > ael > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Strange tags
Hi, I was mapping an area of geologic significance in Scotland, Dob's Linn, today and as I was panning here and there looking at nearby features came across some tags that I have never seen before. They were added back in 2010 so I didn't bother to try to contact the original mapper. Instead, perhaps one of you has stumbled on similar tags in your work. I'm guessing that the tags corbett, donald, graham, and munro were either contributors to the data and their names preserved by user:marscot or something else I can't fathom. In a diary entry from 2009, user:marscot has this to say: "tomorrow I head into the mountains to grab another 3 munros for me and osm, they are Cairn Asoda and Cairnwell, and another one further along." I gather from Google that a "munro" is a peak in Scotland that is less than 3000 ft in height. All fine and dandy, but is that a valid tag? And what is a "donald", or corbett=yes donald=yes ele=821 graham=no man_made=cairn munro=no name=White Coomb natural=peak note=cairn yes source=local_knowledge wikidata=Q7994603 wikipedia=en:White Coomb -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - traffic_calming=dynamic_bump
Thanks for a nice job on the proposal. The new tag seems appropriate as well. I have not seen anything like this in my travels but it sounds like a wonderful idea. Cheers, Dave On Wed, Aug 28, 2019 at 12:34 PM simson.gert...@gmail.com < simson.gert...@gmail.com> wrote: > The wording "bump" is ok in my eyes for the lowered hatch type too because: > > -after you roll down the inclined plane the edge "bumpes" you up again > -I don't think the word "bump" necessarily implies the direction up or a > direction at all. > -The brand name of the device on the pictures is "Actibump" > > Regards > > Am 28.08.2019 um 21:14 schrieb Anton Klim: > > Thanks for the proposal, this is something I haven’t heard of before! > > Not sure if “bump” would be suitable for those that slide down beneath > the surface? Maybe traffic_calming=dynamic/variable? > > > > Regards > > Ant > > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Use of tag "import=yes" on objects, not changesets?
The Facebook team did employ some sort of AI to assist in the identification of highways but it wasn't always right. And the mappers they employed didn't know OSM very well. We met with them several times to offer advice and hints but some of the more active mappers in Thailand are still railing about the failure of the team to come up to speed. They joined OSM, they mapped, they departed. Next up, Grab. Another huge imbroglio resulted. Same issues. Inaccurate mapping, broken routes, especially in Bangkok. The horse has definitely left the barn. We're left with what remains a very large task of cleaning up and verifying. On a positive note, they added thousands of highways for us and made their high-quality DigitalGlobe imagery available to ordinary OSMers. That, to me anyway, was well worth the trade-off. On Sat, Aug 10, 2019 at 9:43 AM Paul Allen wrote: > On Sat, 10 Aug 2019 at 17:27, Dave Swarthout > wrote: > >> The decision to use the import=yes tag wasn't mine nor that of other >> experienced Thailand mappers. The Facebook crew "invented" this use, for >> whatever internal reason(s)of their own and we local mappers simply went >> along with it because we were desperate for a method with which to check >> their work. >> > > If Joseph was right that Facebook used AI on the aerial imagery then I'd > say it does meet some > of the criteria for an import unless the results were first verified by > humans. And since it > sounds like Facebook dumped the unverified AI output into OSM for humans > to check, then > import=yes doesn't sound unreasonable (although it might have been better > as a changeset > tag rather than an object tag). Would something like AI_assisted have > been better? Maybe. > Would a changeset tag have been better? Maybe. Is there any point > locking the stable door > now the horse has bolted? No. Can we persuade Facebook to do it any > differently in the > future? I have my doubts, and I expect Facebook horses will keep bolting > because they > never lock the stable doors. > > -- > Paul > > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Use of tag "import=yes" on objects, not changesets?
The decision to use the import=yes tag wasn't mine nor that of other experienced Thailand mappers. The Facebook crew "invented" this use, for whatever internal reason(s)of their own and we local mappers simply went along with it because we were desperate for a method with which to check their work. On Fri, Aug 9, 2019 at 4:25 PM Joseph Eisenberg wrote: > Thanks, Dave. > > Re: > "Having that tag allows us to easily locate and check the > validity of their work. > > ... After we check the work, we remove the import tag." > > This usage would be incompatible with what I was told about Indonesia: > if they want to use this tag to find how many roads they added, they > probably don't want me to remove it. > > Even for your use-case in Thailand, I think it would be better to use > a different tag, like "computer_vision_assisted" for the facebook > stuff, or something else more specific, since "import=yes" should mean > that the data came from an external source, rather than from on of our > usually sources aerial imagery. > > Joseph > > On 8/10/19, Dave Swarthout wrote: > > The reason those objects (mostly highways) are tagged that way in > Thailand, > > at least, is because much of the mapping done by the Facebook and Grab > > teams was rather poorly executed. Having that tag allows us to easily > > locate and check the validity of their work. One of the regular Thailand > > contributors developed a Map Paint Style that outlines all highways > tagged > > with import=yes in JOSM. After we check the work, we remove the import > tag. > > > > I think this is a valid use for the tag, and it's not meant to be a > > permanent tag in any case. > > > > Cheers, > > > > Dave > > > > On Fri, Aug 9, 2019 at 9:49 AM Paul Allen wrote: > > > >> On Fri, 9 Aug 2019 at 15:23, Frederik Ramm wrote: > >> > >>> > >>> f.s.v.o. "simple", a relatively foolproof method on a Linux machine is > >>> > >>> 1. download indonesia history pbf, > >>> 2. run osmium command line tool to convert into ASCII "opl" format, > >>> 3. grep how many ways with highway=* and v=1 are mapped by their team. > >>> > >> > >> You omitted step 0: install osmium. > >> > >> And possibly step -1: figure out how to compile and install osmium > >> because > >> it's not > >> available as a package for the distro you're using. > >> > >> Yeah, both of those steps ought to be obvious to Linux users. But if > >> somebody > >> puts a Linux distro on an old computer specifically just for this then > >> those are things > >> they need to be aware of. Osmium isn't a standard part of Linux and > it's > >> not available > >> pre-packaged for all distros. > >> > >> -- > >> Paul > >> > >> ___ > >> Tagging mailing list > >> Tagging@openstreetmap.org > >> https://lists.openstreetmap.org/listinfo/tagging > >> > > > > > > -- > > Dave Swarthout > > Homer, Alaska > > Chiang Mai, Thailand > > Travel Blog at http://dswarthout.blogspot.com > > > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Use of tag "import=yes" on objects, not changesets?
The reason those objects (mostly highways) are tagged that way in Thailand, at least, is because much of the mapping done by the Facebook and Grab teams was rather poorly executed. Having that tag allows us to easily locate and check the validity of their work. One of the regular Thailand contributors developed a Map Paint Style that outlines all highways tagged with import=yes in JOSM. After we check the work, we remove the import tag. I think this is a valid use for the tag, and it's not meant to be a permanent tag in any case. Cheers, Dave On Fri, Aug 9, 2019 at 9:49 AM Paul Allen wrote: > On Fri, 9 Aug 2019 at 15:23, Frederik Ramm wrote: > >> >> f.s.v.o. "simple", a relatively foolproof method on a Linux machine is >> >> 1. download indonesia history pbf, >> 2. run osmium command line tool to convert into ASCII "opl" format, >> 3. grep how many ways with highway=* and v=1 are mapped by their team. >> > > You omitted step 0: install osmium. > > And possibly step -1: figure out how to compile and install osmium because > it's not > available as a package for the distro you're using. > > Yeah, both of those steps ought to be obvious to Linux users. But if > somebody > puts a Linux distro on an old computer specifically just for this then > those are things > they need to be aware of. Osmium isn't a standard part of Linux and it's > not available > pre-packaged for all distros. > > -- > Paul > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Road hierarchy
>Different places, different practices. In the rural areas near here, a great many private service ways have names, so that the houses on them will have street >addresses for emergency services to find. Often the name is something like 'Smith Road' because it goes into the Smith family farm. It's just a highway=service >or highway=track access=private, but is named and signed for navigation. That same practice is fairly common in Alaska as well. Tiger often classes these as residentials but like all Tiger data, it must be verified before you can believe it LOL On Mon, Aug 5, 2019 at 11:11 AM Kevin Kenny wrote: > On Mon, Aug 5, 2019 at 1:07 AM Florian Lohoff wrote: > >> Correct - But from my experience its either a service or it has >> a name. At least in the part of Germany where i map. >> >> There are of course the 1% of exceptions where Bayer or BASF names roads >> on their facility property. But the typical parking aisle or >> access to a fuel station should not carry a name. >> >> > Different places, different practices. In the rural areas near here, a > great many private service ways have names, so that the houses on them will > have street addresses for emergency services to find. Often the name is > something like 'Smith Road' because it goes into the Smith family farm. > It's just a highway=service or highway=track access=private, but is named > and signed for navigation. > > I agree that a parking aisle or urban driveway is unlikely to have a name. > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Road hierarchy
Peter wrote: My research tells me ‘unclassified’ means classified as ‘unclassified‘, which is a class of road in the public road system. I respectfully disagree. That is only the case where a country has a class of roads they label or call "Unclassified". In Alaska and Thailand, where I do the bulk of my mapping, an unclassified highway is just that, it is a highway having no classification. I consider it higher in the hierarchy than a residential and lower than a tertiary, although some opinions may differ. Whether paved or unpaved makes no difference. As long as it connects towns or hamlets in a reasonable manner, then it is an unclassified highway. On Sun, Aug 4, 2019 at 10:49 AM Peter Elderson wrote: > My research tells me ‘unclassified’ means classified as ‘unclassified‘, > which is a class of road in the public road system. Other roads cannot be > classified as ‘unclassified’, but should get another classification. Roads > without classification need a fixme, not a classification as ‘unclassified’. > > Mvg Peter Elderson > > > Op 4 aug. 2019 om 16:23 heeft Martin Koppenhoefer < > dieterdre...@gmail.com> het volgende geschreven: > > > > > > > > sent from a phone > > > >> On 4. Aug 2019, at 15:37, Florian Lohoff wrote: > >> > >> A residential is also an unclassified road. > > > > > > IMHO it is not, as an unclassified road is part of the interconnection > grid, while a residential road is not > > > > 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 > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] shop=cannabis including medical cannabis
@Jmapb I agree with all of your points. Reiterating a bit: Using the cannabis:*.* tag to designate a place where one can buy cannabis, be it a pharmacy or a shop=cannabis, or be it for recreational or medical use, will go a long way toward making this scenario both understandable and logical. I wouldn't like using shop=cannabis with amenity=pharmacy on the same object. No way. There would also be an ugly "tag collision" with shop=chemist (whatever that is, LOL). IMO, it would be best to use the tag of cannabis:medical=only for such dispensaries. On Fri, Jun 14, 2019 at 2:56 PM Jmapb via Tagging wrote: > On 6/14/2019 5:33 PM, Dave Swarthout wrote: > > > Martin wrote: > > > > >It would imply adding shop=cannabis to pharmacies? In some countries > > the sale of medicine is restricted to pharmacies. > > > > Not necessarily. IMO, we could also use the cannabis:medical=yes/only > > tag to pharmacies offering it. > > > Yes, my understanding is that shop=cannabis is only for shops whose sole > purpose (or at least clear primary purpose) is the sale of cannabis. It > shouldn't automatically be added to any POI where legal cannabis is > available. > > A pharmacy that sells a variety of medicines should not be tagged as > shop=cannabis, but could still be tagged with cannabis:*=* (similar to > drink:wine=yes at shop=deli.) > > IMO the shop=cannabis tag should not be used at all in any jurisdiction > where legal cannabis is only available through general purpose > pharmacies. (I don't know of any such places, but I assume they exist > somewhere, or will at some point.) And obviously it also shouldn't be > used in jurisdictions where all cannabis sales are illegal. > > J > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] shop=cannabis including medical cannabis
Martin wrote: >It would imply adding shop=cannabis to pharmacies? In some countries the sale of medicine is restricted to pharmacies. Not necessarily. IMO, we could also use the cannabis:medical=yes/only tag to pharmacies offering it. On Fri, Jun 14, 2019 at 12:58 PM Martin Koppenhoefer wrote: > > > sent from a phone > > > On 14. Jun 2019, at 18:26, Jmapb wrote: > > > > An accepted answer to a recent question on help.openstreetmap.org ( > > > https://help.openstreetmap.org/questions/69593/how-to-tag-a-medical-cannabis-dispensary > > ) suggested expanding the definition of shop=cannabis to include > > dispensaries for medical cannabis. > > > > This makes sense to me, and the original discussion ( > > > https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/shop%3Dcannabis > > ) doesn't really give any clear reason for excluding medical cannabis > > shops. (In fact, the subtags cannabis:medical and cannabis:recreational > > are proposed and not disputed.) > > > It would imply adding shop=cannabis to pharmacies? In some countries the > sale of medicine is restricted to pharmacies. > > > Cheers, Martin > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] shop=cannabis including medical cannabis
I strongly agree that the Wiki should be updated to include the tags already in use for medical and recreational use of marijuana. I'm don't understand why the Wiki authors made it so restrictive in the first place. I also agree that these dispensaries are merely special purpose shops and not pharmacies. Furthermore, in the U.S. normal pharmacies do not, AFAIK, sell cannabis. I suggest: cannabis:medical=yes/only cannabis:recreational=yes/only Using these optional tags, shops that sell only medical or only recreational cannabis can be better distinguished. Also, agree that the verbiage about Colorado could be removed. Thanks, Dave On Fri, Jun 14, 2019 at 9:49 AM Jmapb wrote: > On 6/14/2019 1:15 PM, Tobias Zwick wrote: > > Wouldn't medical cannabis be sold in pharmacies? > > The world is vast and diverse, so I imagine the answer is yes. But in > the places I map most (USA), medical cannabis is sold in single-purpose > shops called dispensaries, which do not stock any other medicines. > Calling them pharmacies would be a form of "troll tagging." > > (Of course a pharmacy that does sell cannabis, wherever and whenever > that exists, could be tagged cannabis=yes or cannabis:medical=yes.) > > J > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] refugee camp
I did not add a refugee=yes tag. I tagged it as a place=town because my quick search for alternatives came up empty and there are about 50,000 people living there. That way, at least the camp name shows up on maps and is searchable. I'll retag it based on what we decide here. On Tue, Jun 11, 2019 at 12:06 PM Violaine_Do wrote: > Hi, > > Did you think about adding refugee=yes tag on place=* ? > > There were also an idea, if you have the boundary to develop rules > around boundary, similar to boundary = administrative to > boundary=refugee see > > https://wiki.openstreetmap.org/wiki/Proposed_features/Refugee_Camp_Boundaries > > I also think is is something to dig in and happy to help... > > Best, > > V > > On 11/06/2019 05:39, Jan S wrote: > > > > Am 10. Juni 2019 22:05:53 MESZ schrieb Dave Swarthout < > daveswarth...@gmail.com>: > >> The refugee camps I'm familiar with in Thailand are not social > >> facilities > >> except in an incidental way. They are essentially internment camps > >> surrounded by fences with guarded gates where undocumented aliens are > >> kept. > >> They are landuse=residential because they're isolated areas in the > >> countryside and contain permanent dwellings but having no other way to > >> tag > >> it at the time, I tagged a big refugee camp near Mae Sot as place=town > >> and > >> name=Mae La Refugee Camp. As for the refugee aspect, I made a note and > >> left > >> it at that. > > I have my doubts whether place=town is the appropriate tag for a fenced > living area, where people are obliged to live. Why wouldn't a big prison be > place=town then, too (just have a look at > https://en.m.wikipedia.org/wiki/Palmasola)? > > > > > >> I'm not sure which approach would be better between social_facility, > >> amenity or what have you, but any tourism-related tag definitely will > >> not > >> work. > > My idea of a refugee camp is that there's some kind of social service, > either public or private, like food distribution, medical attention, maybe > housing or tents being provided by the government, UNHCR, or whomever. > Would anything like that apply to the camps in Thailand you've described? > If yes, I wouldn't have issues with using social_facility... > > > > ___ > > Tagging mailing list > > Tagging@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/tagging > > -- > Violaine_Do > > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] refugee camp
The refugee camps I'm familiar with in Thailand are not social facilities except in an incidental way. They are essentially internment camps surrounded by fences with guarded gates where undocumented aliens are kept. They are landuse=residential because they're isolated areas in the countryside and contain permanent dwellings but having no other way to tag it at the time, I tagged a big refugee camp near Mae Sot as place=town and name=Mae La Refugee Camp. As for the refugee aspect, I made a note and left it at that. I'm not sure which approach would be better between social_facility, amenity or what have you, but any tourism-related tag definitely will not work. In this particluar case, place=town is appropriate because it's so large; smaller camps might be tagged as place=hamlet, etc. On Mon, Jun 10, 2019 at 6:04 AM Phake Nick wrote: > If you look at it from a temporary residence for the group of people > perspective, then I guess tags like place=village/town/neighbourhood could > be better choices? > > 在 2019年6月10日週一 20:18，Joseph Eisenberg 寫道： > >> I understand why refugee camps have been mapped with >> amenity=social_facility - it's the closest existing tag, since >> tourism=camp_site is clearly wrong and landuse=residential isn't quite >> right. >> >> However, I don't think that large refugee camps are a perfect fit for >> amenity=social_facility. >> >> Most of these are group homes (eg orphanages), nursing homes (for the >> elderly), hospices, assisted living facilities, homeless shelters, >> outreach facilities for the homelss, etc - they provide services for >> vulnerable groups in the community who have difficulty living on their >> own. >> >> Refugee camps are closer to an informal residential settlement in many >> developing countries, especially those that are larger or have been in >> place for more than a few months (these are the ones most likely to be >> mapped, I believe). >> >> I would encourage creating a proposal and a new tag specifically for >> these sorts of places. There could perhaps be a distinction between >> sites for people temporarily displaced locally (eg a camp for people >> in the same town, after a flood) versus long-distance or international >> migrants. >> >> On 6/10/19, Jan S wrote: >> >> >> >> On 6/6/2019 5:27 PM, Graeme Fitzpatrick wrote: >> >> >>* I'd suggest something like social_facility=temporary_housing. >> >> *>>>* To me, social_facility doesn't quite cut it for "refugees". >> >> Refugees >> >> *>* strike me as people fleeing from war / massive natural disaster - >> >> *>* social_facility comes across as small scale for homeless people / >> >> *>* women's refuge sort of thing? >> >> *>>Browsing through the values of social_facility:for, it's a lot more >> >> diverse than just victims of abuse and poverty -- and >> >> social_facility:for=refugee(s) has hundreds of uses. But you definitely >> >> have a point about scale -- some of these camps house over a hundred >> >> thousand people. That's on the scale of a small city -- a community, >> not >> >> a facility. So maybe place=refugee_camp is a better solution. >> >> >> >> J >> >> >> >> >> > Picking up the subject again (and having noticed that the refugee camps >> I >> > know in my area are not tagged at all or at least very rudimentary >> simply >> > as amenity=social_facility), I've done another search on the internet >> and >> > have dug up this wiki page: >> > https://wiki.openstreetmap.org/wiki/Refugee_Camp_Mapping >> > >> > It's been modified in 2018 for the last time, is quite rudimentary in >> the >> > description of the tags and values proposed and apparently oriented >> mainly >> > at makeshift camps in Africa or the Levante. It would be an effort to >> bring >> > some order into this and to make it more diverse (covering anything from >> > spontaneous camps like the infamous Jungle in Calais or the already >> > dismantled Idomeini camp, to permanent structures like asylum-seeker >> > reception centres like this: >> https://www.openstreetmap.org/way/390153052). >> > >> > I'll see if I can give it a try over the next weeks... or would that be >> a >> > task for a coordinated action? >> > >> > Best, Jan >> > >> >> ___ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Complicated traffic light combinations
There is a switch in the Show submenu of the Configure Map menu named OSM Notes, Flick it on and the notes appear. Dave On Thu, Jun 6, 2019 at 10:52 PM Graeme Fitzpatrick wrote: > > > On Fri, 7 Jun 2019 at 09:35, Dave Swarthout > wrote: > >> Actually, OSMand will display notes if you enable that feature. It's a >> useful tool if you happen to be an OSM mapper. >> > > I know you can see the Description & as well as various tag details, but > how do you see Notes, thanks Dave? > > Thanks > > Graeme > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Complicated traffic light combinations
Actually, OSMand will display notes if you enable that feature. It's a useful tool if you happen to be an OSM mapper. On Thu, Jun 6, 2019, 3:21 PM Warin <61sundow...@gmail.com> wrote: > On 07/06/19 08:58, Andy Townsend wrote: > > Hello, > > > > I've just mapped the traffic lights for a river crossing in > > https://www.openstreetmap.org/changeset/71005300 (Elvington in > > Yorkshire, England). > > > > > Along with which direction the light points and what traffic it is > > designed to control I've added the button info only as note tags at > > this stage, but is there a better way of doing this? > > I don't think the 'note' key is used by renders, it is mean for > communication between mappers. > I would use the 'description' key as it may go on to maps so that may > communicate to both mappers and map users. > > ___ > 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] tracktype=*;*;*
I've occasionally seen mappers do this sort of thing intentionally. They may know (or guess) that a particular way has more than one tracktype so they simply add other values and separate them with a semicolon. In such cases, if one cannot determine what the tracktype actually is, it might be better to simply delete the entire tag. Unless you want to create a changeset comment or contact the original mapper some other way. On Thu, May 9, 2019 at 1:39 PM Florian Lohoff wrote: > On Thu, May 09, 2019 at 01:37:09PM -0600, brad wrote: > > I'm seeing some tracks with multiple tracktype's like this: > > > > Way 364707088 [highway=track, name=FR 514, > tracktype=grade2;grade1;grade3] > > > > Is this generally accepted practice? > > If so, why? > > IMHO does not make sense at all. Most likely somebody joined track > segments without noticing the different grades and the editor > joined it. > > Flo > -- > Florian Lohoff f...@zz.de > UTF-8 Test: The ran after a , but the ran away > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Avoid using place=locality - find more specific tags instead
Joseph wrote: We recently discussed place=locality, and I now believe this tag should be avoided, and perhaps deprecated." I cannot agree. In the case of Alaska, these named places are so remote that there is no chance of me (or any other OSM mapper for that matter), ever doing a survey to determine if those place names are in use by locals (trappers hunters, canoeists) or not. I'm willing to change my tagging practices and ADD a new and better designed tag reflecting the status of such places as can best be determined from DigitalGlobe imagery but I am certainly not going to remove the place=locality tag from them. Warin's question is also relevant: what about place=island or place=islet? FYI, Alaska currently has more than 500K nodes, 5646 ways and 186 relations that represent either a place=island or place=islet and I'm still adding more of them daily. @MarKus: Regarding the tagging of islands or lake groups (clusters), I've already begun to use the type=group tag and hope that someone will push OSM-Carto to render such relations in the future. On Tue, Apr 16, 2019 at 5:26 AM Markus wrote: > Hi > > On Tue, 16 Apr 2019 at 09:40, Joseph Eisenberg > wrote: > > > > Two of the examples need new tags created: > > 3 lakes with a name: needs a new tag, perhaps natural=lake_group as a > > multipolygon relation? > > There is already a proposed and used type=group relation for all kind > of named groups: > > https://wiki.openstreetmap.org/wiki/Proposed_features/Group_Relation > > Regards > > Markus > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Subtag for place=locality?
> Can you give an example of one of these groups of named islands? If they are close together and divided from other islands in the area, I would use “archipelago”. Here's a small group of only two islands that is definitely not an archipelago, (as I understand that term, i.e., a "chain" of islands), and have one name to describe both islands, the Leland Islands: https://www.openstreetmap.org/way/20287799#map=14/58.6562/-135.9916 In this case, the original mapper didn't tag them as a multipolygon but applied the place=island tag to the group as a node. I fact, he didn't even bother to redraw the horrible PGS coastline to separate them into individual islands. Alaska has hundreds of these island groups. On Mon, Apr 15, 2019 at 7:12 PM Warin <61sundow...@gmail.com> wrote: > On 15/04/19 22:04, Joseph Eisenberg wrote: > > That's an interesting example. Was the wheel put there as a landmark > > or route marker, or just for fun? > > I don't know. I would assume as a landmark, to form a meeting place or a > simple navigational aid. I don't even know if the present wheel is the > original one. > > > > > If the tag "place=locality" didn't exist, how would you tag this? > > I'd ask here, that is one of the things this group is good for. > > > > > On 4/15/19, Warin <61sundow...@gmail.com> wrote: > >> As an example of a locality that has never had a population > >> > >> https://www.openstreetmap.org/node/117041320 > >> > >> /The Wheel/ (a car wheel - no tyre) was originally mounted on a tree by > >> bushwalkers to mark the hub of the Blue Labyrinth's ridges. > >> > >> No one has ever lived there. Plenty of people go past, and it still a > >> navigational feature. > >> > >> Fairly certain other localities have their stories to tell too. > >> > >> > >> n 15/04/19 17:23, Warin wrote: > >>> From the original start of place=locality > >>> > >>> /All current place tags are for either populated areas, or for larger > >>> areas of County sized or bigger. The place=locality tag is useful for > >>> places that have a specific name, but do not necessarily have any > >>> geographic feature or population centre that could be used to attach a > >>> name tag to. / > >>> > >>> That to me suggest that places that locality can be a place that had > >>> population, or places that did not have a population. > >>> > >>> But, I agree, that places that had a population would be better tagged > >>> disused:/abandonded: place=hamlet/town/village/city > >>> > >>> I think that can go on the wiki for locality... under 'when not to > >>> use' with the others there. > >>> / > >>> / > >>> On 15/04/19 17:03, Martin Koppenhoefer wrote: > >>>> > >>>> sent from a phone > >>>> > >>>> On 15. Apr 2019, at 03:55, Joseph Eisenberg > >>>> mailto:joseph.eisenb...@gmail.com>> > wrote: > >>>> > >>>>> The most important value would be one for a locality that is a former > >>>>> populated place but no longer has a population. > >>>> > >>>> I’ve always understood the population part of the locality tag > >>>> definition as a way of saying the place name does not relate to a > >>>> settlement or dwelling (but it doesn’t necessarily mean nobody is > >>>> living around there, it means this name is not for an inhabited > >>>> place). A generic tag for a place name/ toponym, to be used where no > >>>> specific tag has yet been developed. > >>>> (e.g. we have specific tags for toponyms that refer to mountain > >>>> peaks, wetlands, lakes, islands, deserts, caves, settlements, etc. so > >>>> we don’t use locality for them) > >>>> > >>>> I’m not sure I’d support locality subtags, for lots of things a main > >>>> tag might be more fitting with the established tagging system, but it > >>>> depends on the actually proposed values. > >>>> > >>>> For ghost towns (settlements) I’ve found a lot tagged as > >>>> abandoned:place=hamlet/village/town > >>>> > >>>> https://taginfo.openstreetmap.org/keys/abandoned:place#values > >>>> > >>>> which seems inline with the rest of our tagging and is by far more > >>>> frequent than any “ghost” variations. > >>>> > >>>> Cheers, Martin > >>>> > >>>> > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Subtag for place=locality?
Joseph wrote: There is a request to render place=archipelago now (Issue #3394); I will look into it. It's only used 740 times, so it would help if more people start using the tag. It would certainly be useful here in Indonesia. (BTW, I would recommend tagging archipelagos as simple nodes or as multipolygon relations that include all of the islands. The wiki pages suggests using a "type=cluster" relation, but this would be hard to use) The groups of islands I mentioned to are not archipelagos but merely several islands sharing a name. The same logic applies to named groups of lakes, for example, Three Lakes ( https://www.openstreetmap.org/relation/6714525), which I tagged as a multipolygon. Lately, as a result of a discussion on this list, I've begun using type=group for this sort of feature. OSM Carto doesn't render either type=cluster or type=group multipolygons so many mappers will no doubt continue to use type=multipolygon for them. I'm willing to add a more specific tag for abandoned localities if we can decide exactly which one of the several alternatives is the best candidate. Of course, 99% of such places in Alaska cannot be inspected in person to decide if foundations and infrastructure exist because they are incredibly remote. One has only satellite imagery with which to envision what's on the ground. That's one reason I fall back to simply using the abandoned=yes tag. On Mon, Apr 15, 2019 at 1:15 PM Kevin Kenny wrote: > On Mon, Apr 15, 2019 at 12:49 PM Volker Schmidt wrote: > >> A side remark. Triggered by comparing abandoned palces with abandoned >> railways (and smilar), >> a ghost town with (some) buidlings still standing should be abandoned: ... >> a ghost town without trace on the ground should be tagged with razed: ... >> or dismantled: ... , but not with abandoned: ... >> Example: https://www.openstreetmap.org/node/150938807 >> This is a former town, of which you do no see any trace on the ground any >> more (apart from a few racks) >> > > I thought that the commoner lifecycle prefix was 'demolished' ? > > I use 'disused' if the buildings are relatively well preserved and might > be rehabbed, 'abandoned' if they're ruined, 'demolished' if the buildings > are not standing but the settlement is still observable. Most of the ghost > settlements that I've visited have clearly visible building foundations, > stone walls separating fields, and road grades (which may be grown to > trees, but are still obviously artificially graded) and are thus > 'demolished.' (The ones on State land have likely had their buildings burnt > to discourage squatters.) Theymay also have formations like tannery vats, > mine shafts, mill races or cellar holes. > > https://www.flickr.com/photos/ke9tv/8690778427 is typical of 'demolished' > - the road has mature trees standing in it and is not passable for any > distance by anything on wheels, but the fact that the area was once a > settlement is obvious. (I've found the remains of a mill, a tannery, and a > forge in that former settlement, but have not been able to discover even > its name.) > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Subtag for place=locality?
Yes, that's one locality for every four persons in the state, an interesting statistic. Many of these are indeed GNIS imports and some of those are also tagged with "gnis:Class": "Populated Place" which is often inaccurate. I'm certain the gold rushes Alaska experienced during the past 150 years contributed to many of these abandoned "Populated Places". Some of them were quite large (several thousands of inhabitants) but as gold became scarcer and more difficult to extract from the ground, were abandoned. I typically add only the abandoned=yes tag on any feature that either appears to be or is known to be deserted. I tag a typical abandoned place=locality with only the name, the source, the abandoned=yes tag and occasionally with a description if I think it's interesting enough. Some of this information is found in a very useful public domain publication, the Dictionary of Alaska Place Names, which contains a wealth of information about such localities. I use it constantly in my Alaska mapping work. I don't have a good guess as to the validity of the existing localities nor can I estimate how many might be actually natural features like mountain_range or valleys but there are definitely plenty of those. Sometimes people tag groups of islands with the locality tag as opposed to creating a relation of some sort. It's a much simpler solution and provides the mapper assurance that it will render. I don't use that approach because I don't think it's correct. On Mon, Apr 15, 2019 at 7:29 AM Joseph Eisenberg wrote: > > There are countless old settlements, gold mining camps, road building > > camps, airstrips, and even Native American villages scattered around our > > immense state. Most are indeed abandoned and sometimes I add > abandoned=yes > > to the tags, especially if there is no longer any sign of habitation > > visible on satellite imagery. > > Thanks Dave, > > What tags do you usually add for a former settlement, or for an > abandoned gold mining or road building camp? > > Are you using just place=locality with abandoned=yes, or is the tag > "abandoned" always referring to a more specific feature, like > historic=mine or aeroway=aerodrome? > > > An Overpass query returned almost 190,000 nodes along with 417 ways and > 46 > > relations tagged as place=locality, that are located in Alaska. > > There are 750k people in Alaska, so there's more than one locality for > every 4 people! > > Clearly most of these were imported, probably from GNIS(?). > > In your experience, how many of the imported locality nodes seem to be > correctly tagged? > > Could many of them be something more specific, like natural=valley, > natural=ridge, natural=peak, natural=bay, railway=junction, > highway=junction, place=island, etc? > > Joseph > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Subtag for place=locality?
As a mapper in Alaska, I rely heavily upon the USGS Topographic map layer to provide names for geographic features. Alaska has many places that perfectly fit the definition Warin provided from the Wiki: *All current place tags are for either populated areas, or for larger areas of County sized or bigger. The place=locality tag is useful for places that have a specific name, but do not necessarily have any geographic feature or population centre that could be used to attach a name tag to. * Given Alaska's gold mining history, I encounter such places all the time. There are countless old settlements, gold mining camps, road building camps, airstrips, and even Native American villages scattered around our immense state. Most are indeed abandoned and sometimes I add abandoned=yes to the tags, especially if there is no longer any sign of habitation visible on satellite imagery. An Overpass query returned almost 190,000 nodes along with 417 ways and 46 relations tagged as place=locality, that are located in Alaska. AlaskaDave On Mon, Apr 15, 2019 at 3:34 AM Warin <61sundow...@gmail.com> wrote: > As an example of a locality that has never had a population > > https://www.openstreetmap.org/node/117041320 > > *The Wheel* (a car wheel - no tyre) was originally mounted on a tree by > bushwalkers to mark the hub of the Blue Labyrinth's ridges. > > No one has ever lived there. Plenty of people go past, and it still a > navigational feature. > > Fairly certain other localities have their stories to tell too. > > > n 15/04/19 17:23, Warin wrote: > > From the original start of place=locality > > *All current place tags are for either populated areas, or for larger > areas of County sized or bigger. The place=locality tag is useful for > places that have a specific name, but do not necessarily have any > geographic feature or population centre that could be used to attach a name > tag to. * > > That to me suggest that places that locality can be a place that had > population, or places that did not have a population. > > But, I agree, that places that had a population would be better tagged > disused:/abandonded: place=hamlet/town/village/city > > I think that can go on the wiki for locality... under 'when not to use' > with the others there. > > > On 15/04/19 17:03, Martin Koppenhoefer wrote: > > > > sent from a phone > > On 15. Apr 2019, at 03:55, Joseph Eisenberg > wrote: > > The most important value would be one for a locality that is a former > populated place but no longer has a population. > > > > I’ve always understood the population part of the locality tag definition > as a way of saying the place name does not relate to a settlement or > dwelling (but it doesn’t necessarily mean nobody is living around there, it > means this name is not for an inhabited place). A generic tag for a place > name/ toponym, to be used where no specific tag has yet been developed. > (e.g. we have specific tags for toponyms that refer to mountain peaks, > wetlands, lakes, islands, deserts, caves, settlements, etc. so we don’t use > locality for them) > > I’m not sure I’d support locality subtags, for lots of things a main tag > might be more fitting with the established tagging system, but it depends > on the actually proposed values. > > For ghost towns (settlements) I’ve found a lot tagged as > abandoned:place=hamlet/village/town > > https://taginfo.openstreetmap.org/keys/abandoned:place#values > > which seems inline with the rest of our tagging and is by far more > frequent than any “ghost” variations. > > Cheers, Martin > > > ___ > Tagging mailing > listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging > > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Was barrier=jersey_barrier approved in a proposal?
>From Wikipedia: Jersey barriers were developed in the 1950s, beginning in the U.S. state of New Jersey <https://en.wikipedia.org/wiki/New_Jersey> as separators between lanes of a highway. Over time, they grew taller (as their effectiveness was demonstrated) and became more modular (as their usefulness as temporary barriers became apparent). Taller barriers have the added advantage of blocking most oncoming headlights. So it has an American heritage. Seeing as it's a widely used term in OSM, I'd say it's a small payback for forcing us to use the English spelling of things like centre and neighbourhood. LOL Dave On Sun, Apr 14, 2019 at 3:57 AM Martin Koppenhoefer wrote: > > > sent from a phone > > On 14. Apr 2019, at 04:43, Joseph Eisenberg > wrote: > > I want to know so that the wiki page can be edited to show the correct > status: approved vs in use. > > > > I went back into the archives and it seems it was included and approved in > my more barrier types proposal 2011: > https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/New_barrier_types=684703 > Not sure where the tag name for jersey barriers came from, probably from > tagging ml discussion (it is not a word I have in my vocabulary) > > Cheers, Martin > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Clarification unclassified vs residential
Whoa, What happened to the original topic of this thread? We were trying to come up with a system of determining whether a highway is classified or residential. Now we're talking about traffic density and traffic speed, and some sort of numerical classification scheme for motorways, etc. What's going on? Signed, Confused in Thailand. (AlaskaDave) On Tue, Feb 26, 2019 at 12:28 PM Warin <61sundow...@gmail.com> wrote: > On 26/02/19 10:59, Sergio Manzi wrote: > > +1 here too, and a little bit of the same concerns expressed by Andy ( > https://xkcd.com/927/) > > BTW, in the Italian mailing list there is currently a thread discussing if > and how we should tag highways according to what are the official > categories in the Italian Traffic Code (*Codice della Strada*) are. > > There the concern is most about how to tag an official classification > (*something > that is implicit in the tag value in UK, if I'm not mistaken*) instead of > a "descriptive classification". > > Is ther a UK page that has these official classifications? They maybe of > use to fit others classifications to. > > But other concerns are emerging too (*at least in my head!*), like the > administrative responsibility under which a given road falls (*state, > region, province, municipality, private*) > > Use operator=* ??? > > and ad-hoc values as input for the router (*s**peed limits, traffic > density, etc.* > > > Rather than the density.. traffic speed could be more usefull? Example > traffic_speed=20 @ 6:00-19:00 Mon-Fri , traffic_speed=15 @ 9:00-17:00 > Sat-Sun (yes, busier on the weekends!) > *. *If no traffic_speed then routers use the max_speed.. > > * *OR* a comprehensive "preference"value *). > > Keep on going! > > Cheers, > > Sergio > > > > On 2019-02-25 22:10, Andy Townsend wrote: > > On 24/02/2019 14:25, djakk djakk wrote: > > > I think we should decorrelate the attributes of a road : its > administrative class, its importance in the road network (at least 5 > levels), its physical characteristics (motorway-like, two large lanes, > link=yes ...), possibly its traffic characteristics. > > So we can tag a secondary motorway or a primary road through a residential > area or an official motorway with pedestrians actually walking on it. > > So that we’ll unify osm road classification through the world (remember > the highway=trunk issue ;-)) > > > It's a noble aim, but unfortunately the first thing that springs to mind > is https://xkcd.com/927/ :) > > However, some of the stuff on > https://wiki.openstreetmap.org/wiki/User:Djakk/new_tagging_scheme_for_roads > I definitely agree with, and in some cases actually do do myself - like > trying to capture the physical characteristics wherever relevant. > > Best Regards, > > Andy > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > > > > ___ > Tagging mailing > listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Clarification unclassified vs residential
> Most residential roads now are tagged as unclassified, I just > have to list them, determine if the default fits, then retag them as > highway=road. Andy replied: "Tagging roads that you know well as "highway=road" sounds like a mistake" +1 I agree. Tagging highway=road means: I don't have any idea what sort of road this is (but I can see it on the satellite imagery). I hope these roads are never considered to be routable. The mkgmap program's standard style defaults to that conclusion, IIRC. I think of it more or less as a place holder, a way that needs a closer look. Others have stated that they think of an unclassified way as something having more significance than a residential way while still being less important than a tertiary highway. (By the way, in Thailand, coincidentally, a tertiary highway is the lowest class of highway that carries a ref.). And that has been my assumption right along. Where do we stand on that question? Is that the correct question to b asking? On Sat, Feb 23, 2019 at 8:16 PM Peter Elderson wrote: > I was thinking further about the idea that came up here: deduct road type > from the landuse=residential. It's different than current usage, and I dont > think it is feasable. > > > Vr gr Peter Elderson > > > Op za 23 feb. 2019 om 14:02 schreef Andy Townsend : > >> On 23/02/2019 11:36, Peter Elderson wrote: >> > The tagging scheme should have a clear intention to facilitate >> > rendering and routing. Then renderers and routers know what there is, >> > so they can decide how to handle it. >> >> >> To be clear, "highway=road" is used when it _isn't_ clear what the >> classification should be. >> >> >> > >> > If residential area means that road class is highway=residential >> > unless taggted otherwise, that should be made very clear. >> >> >> No, it doesn't. >> >> >> > At the moment, I don't think it is clear, and road tagging in >> > residential areas in Nederland certainly does not follow this principle. >> >> >> That's good! >> >> >> > If the scheme is adopted and very clearly documented, I could adjust >> > the residential road tagging in my village (pop 25.000) in a couple of >> > hours. Most residential roads now are tagged as unclassified, I just >> > have to list them, determine if the default fits, then retag them as >> > highway=road. >> >> >> Tagging roads that you know well as "highway=road" sounds like a mistake. >> >> >> > >> > The problem with such a default of course is: if the area is altered, >> > roads may (and will) unintentionally change because suddenly the >> > default applies or no longer applies. Also, wouldn't renderers and >> > routers will have to deal with roads crossing the border of a >> > residential area suddenly changing types, without a node to tie the >> > action to? >> >> >> I think there's been a miscommunication here - there is no such >> default. It's certainly not your fault - English as used to describe >> roads in the UK is the problem, with "unclassified" meaning a particular >> explicit classification. >> >> Best Regards, >> >> Andy >> >> >> >> ___ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Clarification unclassified vs residential
the German Forum by years - I was >> astonished >> finding statements in the German article for unclassified which do not >> match >> (but oppose) the English versions which i typically use and prefer. >> >> Its not the first time i find the German articles to contain a hidden >> agenda bei a minority or single mappers trying to steer the community. >> >> Flo >> -- >> Florian Lohoff f...@zz.de >> UTF-8 Test: The ran after a , but the ran away >> ___ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Clarification unclassified vs residential
While I agree with Georg's assessment in general, I want to point out that in Thailand I often do downgrade an unclassified highway when it enters a residential area because the differences between the two ways can be significant. You will be driving along on a nice, smooth, two-lane highway and when it enters a hamlet it might transform into a very narrow one-lane street lined with houses. My intent when tagging is to indicate that the highway when it passes through a town is not in any way a high-speed thorofare. I was under the impression that "downgrading" it to residential would help routers evaluate various alternative routes better. So, yes, I do perceive an unclassified highway to be more significant than a residential highway in several ways, speed, convenience, and also safety. On Wed, Feb 20, 2019 at 5:05 PM Georg Feddern wrote: > Am 20.02.2019 um 10:22 schrieb Florian Lohoff: > > So for me retagging residential to unclassified is broken under the > assumption that unclassified is something "better" than residential. > > It is even more broken when there is residential usage in which case > unclassified is inappropriate. > > While discussing i found that there was some modification to the German > version of unclassified not saying that unclassified is something > "better" but suggesting that an unclassified should be dragged into > city limits until the next higher class street. This lets user > assume that unclassified is some higher priority than residential. > > > I was treating those streets identical for the last 10+ years and only > the city limits gave the indication whether to use unclassified or > residential. > > Am i wrong with that usage? > > > Even the english wiki says: > "The tag highway <https://wiki.openstreetmap.org/wiki/Key:highway>= > unclassified is used for minor public roads typically at the lowest level > of the interconnecting grid network." > > As part of the interconnecting grid network it should connect to at least > unclassified or higher roads - unless it is a dead end settlement. > Tagging a through connecting road only because it is inside a city limit > as residential makes no sense. > And usually a connecting road from outside a city limit has at least a bit > more traffic as an inner-city-only residential. > So the conclusion an unclassified has a bit higher priority than a > residential is not far from reality. > > Otherwise there is often the problem to tag the main access roads inside a > bigger residential area. > The practice to tag those as unclassified for a bit higher priority may > not be optimal - but suitable. > > This discussion - and usage - is some years old now - and I thought you > had at least knowledge of it from the german forum. > > Georg > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Clarification unclassified vs residential
That is a most interesting question. Here in Thailand I interpret their differences, perhaps incorrectly, as residential meaning a way with houses on it, while an unclassified highway is one step below a tertiary and therefore one step above a residential. It does not have many houses (residences) and is often a connector between minor towns or villages. Which is more important? In my opinion, an unclassified highway would offer faster transit times than a residential so I'm surprised to learn that routers rate them the same. It's a tricky distinction. I hope this thread will help clarify that distinction. On Wed, Feb 20, 2019 at 4:24 PM Florian Lohoff wrote: > > Hi, > i found some changesets downgrading streets to unclassified. After some > discussions the mapper were under the impression that unclassified is > something higher priority than residential. > > From my long tagging practice in OSM unclassified and residential are > identical in respect to priority. (And e.g. OSRM treats them equal) > The first is used as a connecting road off city limits. The latter is > used for the lowest class roads within city boundarys (Where there is > residential usage) > > So for me retagging residential to unclassified is broken under the > assumption that unclassified is something "better" than residential. > > It is even more broken when there is residential usage in which case > unclassified is inappropriate. > > While discussing i found that there was some modification to the German > version of unclassified not saying that unclassified is something > "better" but suggesting that an unclassified should be dragged into > city limits until the next higher class street. This lets user > assume that unclassified is some higher priority than residential. > > > I was treating those streets identical for the last 10+ years and only > the city limits gave the indication whether to use unclassified or > residential. > > Am i wrong with that usage? > > Flo > -- > Florian Lohoff f...@zz.de > UTF-8 Test: The ran after a , but the ran away > _______ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fwd: [tagging] Canoe route / nautical channels
Sure, it works for me. I've only mapped one canoe route so far and, based on this thread, have already added the waterway=fairway tag to all the previously untagged ways in the route. On Wed, Feb 20, 2019 at 4:12 AM Graeme Fitzpatrick wrote: > > On Wed, 20 Feb 2019 at 01:30, Fernando Trebien > wrote: > >> >> I've applied the two fairway tags to a major fairway on a lake [1][2], >> please let me know if you think anything should be mapped differently. >> > > At first glance, it seems to work, thanks Fernando. > > Dave / Kenny - would it also work for your canoeing purposes? > > Thanks > > Graeme > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fwd: [tagging] Canoe route / nautical channels
"Direction of flow" isn't quite right for a canoe route that crosses a lake. Also, it would be rare but not impossible, for a canoe route to move against the flow when traversing a stream. But, unless someone can think of a better way to word this, I'm okay with what's there. Such refinements can be made in the route relation perhaps. Direction "forward" or "backward" come to mind although I've never used them for a canoe route myself. The only canoe route I've ever mapped can be traveled in either direction if one wishes. Dave On Sat, Feb 16, 2019 at 5:49 AM Graeme Fitzpatrick wrote: > > On Sat, 16 Feb 2019 at 00:12, Fernando Trebien > wrote: > >> >> For well-known partially unmarked shipping routes, I think there would >> be no problem lifting the requirement of navigation marks. But I'm not >> sure if this applies to canoe routes, which are usually not marked. >> I'm neither a sailor nor a native English speaker, so I think I'd >> better leave this decision to those experienced in marine navigation. >> > > Going off my own knowledge of small craft, along with Dave & Kevin's canoe > experience :-), I've edited the page as discussed above > https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dfairway > > Are we all happy with that? > > Thanks > > Graeme > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fwd: [tagging] Canoe route / nautical channels
>So waterway=fairway applies anywhere, but if it's a "major" (marked) channel, then it also gets seamark:type <https://wiki.openstreetmap.org/wiki/Key:seamark:type>=fairway <https://wiki.openstreetmap.org/wiki/Tag:seamark:type%3Dfairway>. >Does that work? Yes, indeed. That would work very well IMO. As Kevin pointed out, I have used route=canoe in a relation but without adding a tag to the ways, most maps either cannot, or choose not to, render them so you're left with footways that end on both sides of a lake (the portages) with no connection between them. Solving this problem is the reason I made my suggestion. Dave On Thu, Feb 14, 2019 at 4:45 AM Graeme Fitzpatrick wrote: > > On Thu, 14 Feb 2019 at 04:05, Fernando Trebien > wrote: > >> On Tue, Feb 12, 2019 at 10:49 AM Dave Swarthout >> wrote: >> > >> > The seamark definition in the supplied link is very general. I cannot >> see how anyone could misinterpret this use of either waterway=fairway or >> seamark:type=fairway unless they are specialists, in which case I'm sure a >> response will be forthcoming. Regardless, I agree that the conflict note >> should be removed. >> >> I've updated the wiki, please have a look and let me know if you >> disagree. [1] >> >> > but I also hope we can somehow make it applicable to canoe routes as >> well. >> >> From the definition of waterway=fairway, it can be used for the >> members of canoe routes as long as they are artificial and marked by >> buoys. I expect this to be rare though. >> > > I'd suggest a slight change of wording to clarify it even further: > > "A navigable route in a lake or sea. If the navigable area is marked by > buoys or navigation markers, it should also be mapped with seamark:type > <https://wiki.openstreetmap.org/wiki/Key:seamark:type>=fairway > <https://wiki.openstreetmap.org/wiki/Tag:seamark:type%3Dfairway>." > > So waterway=fairway applies anywhere, but if it's a "major" (marked) > channel, then it also gets seamark:type > <https://wiki.openstreetmap.org/wiki/Key:seamark:type>=fairway > <https://wiki.openstreetmap.org/wiki/Tag:seamark:type%3Dfairway>. > > Does that work? > > Thanks > > Graeme > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fwd: [tagging] Canoe route / nautical channels
Certainly, the portion of a canoe trail that crosses a lake or pond is indefinite. I assume also that any part that travels along a river would tend to follow its centerline. Such portions of a route can also be tagged as indefinite=yes but what do people think about the canoe route as waterway=fairway idea? On Tue, Feb 12, 2019 at 9:12 PM Kevin Kenny wrote: > On Tue, Feb 12, 2019 at 7:49 AM Dave Swarthout > wrote: > > > > The seamark definition in the supplied link is very general. I cannot > see how anyone could misinterpret this use of either waterway=fairway or > seamark:type=fairway unless they are specialists, in which case I'm sure a > response will be forthcoming. Regardless, I agree that the conflict note > should be removed. > > > > I would love to see the tag waterway=fairway accepted but I also hope we > can somehow make it applicable to canoe routes as well. A canoe route is > not as well defined as a shipping channel, for example, but it does have a > preferred path and well-defined put-in and take-out points. It does not, > however, typically have marker buoys or lights. If we removed that > requirement or made it optional, that would save a lot of energy in trying > to get a modification approved later. So, instead of saying: " A navigable > route in a lake or sea marked by buoys", it might say, "A navigable route > in a lake or sea usually marked by buoys. In the case of a fairway > describing a canoe route, there would typically be no buoys." > > > > Opinions? I think the fairway tag fits so well it might be appropriated > for use on such routes anyway. > > We recently were also discussing the idea of having an > 'indefinite=yes' tag to mark the indefiniite portion of the closed set > of ways that encloses a peninsula, isthmus, bay, strait, or similar > form. Is the on-water portion of a canoe route an indefinite way? (I > would imagine that portages are usually quite definite, but I've > carried on a few where the mud was only slightly too thick to pole or > paddle through.) > > It appears that the nearest thing on the seamark schema is > https://wiki.openstreetmap.org/wiki/Seamarks/Leading_Lines - and it > states specifically that the centreline of a fairway should not be > mapped. In the nautical world, there are usually well-defined and > charted limits of safe navigation, so that a fairway will be bounded > by clearing lines. In the canoe world, it is for the boatman to decide > where safe water is at the lake's current height or the river's > current rate of flow. > > I'd imagine that a canoe route that follows a river would ordinarily > share the river "centerline" or Thalweg with the 'river' object, > except for where it comes ashore to portage or is plotted in a > specific track around obstacles. On a paddle-and-portage from lake to > lake, the waterway portions are quite indefinite indeed! > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fwd: [tagging] Canoe route / nautical channels
The seamark definition in the supplied link is very general. I cannot see how anyone could misinterpret this use of either waterway=fairway or seamark:type=fairway unless they are specialists, in which case I'm sure a response will be forthcoming. Regardless, I agree that the conflict note should be removed. I would love to see the tag waterway=fairway accepted but I also hope we can somehow make it applicable to canoe routes as well. A canoe route is not as well defined as a shipping channel, for example, but it does have a preferred path and well-defined put-in and take-out points. It does not, however, typically have marker buoys or lights. If we removed that requirement or made it optional, that would save a lot of energy in trying to get a modification approved later. So, instead of saying: " A navigable route in a lake or sea marked by buoys", it might say, "A navigable route in a lake or sea usually marked by buoys. In the case of a fairway describing a canoe route, there would typically be no buoys." Opinions? I think the fairway tag fits so well it might be appropriated for use on such routes anyway. Dave On Tue, Feb 12, 2019 at 7:00 PM Fernando Trebien wrote: > Sorry to bring this back so much time later. I just want to confirm a > detail. > > On Tue, Jul 3, 2018 at 8:34 AM Multi Modaal wrote: > > > I could go along with the extension of the definition of > waterway=canal to > > > cover also navigation channels in larger bodies of water, if this > solution > > > is accepted as a result of voting process on a formal proposal. > Personally > > > I prefer a new tag for nautical or navigation channels. > > I agree that a new tag (waterway=lake seems fine to me) would be better, > but until that is formally proposed and widely accepted by data users I see > no advantage in banning current practice which is also in concordance with > the wiki for instance waterway=fairway (fairway on a lake is added as an > addition to waterway=canal/river ) > > Since 27 March 2018, the wiki [1] says that waterway=fairway is > "questioned and conflicts with seamark:type=fairway", but I think this > is not correct. The wiki also states that waterway=fairway should be > used on ways and that seamark:type=fairway should be used on closed > ways, so I believe that a complete description includes both a > navigable area and a line through it (which is typically a requirement > for routing). > > If you agree, I think the conflict note should be removed from the wiki. > > Regards, > > [1] > https://wiki.openstreetmap.org/wiki/Template:Generic:Map_Features:waterway > [2] https://wiki.openstreetmap.org/wiki/Seamarks/Seamark_Objects > > -- > Fernando Trebien > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] motorcycle:scale
@Paul Agreed, and you still must produce a new Wiki page regardless. That's the process most people, including me, try to avoid. Hell, even if we all agreed that a new "category" for Wiki tagging-related pages (which is what I presume we're talking about here) is a good idea, it's a long way from that to reaching consensus. Or am I missing your point totally? On Thu, Feb 7, 2019 at 8:03 PM Paul Allen wrote: > On Thu, 7 Feb 2019 at 12:12, Dave Swarthout > wrote: > >> >> I like the idea of the "informal" category but isn't that more or less >> the same as "proposed"? >> > > The proposal process is formal. It's documented, people scream at you if > you don't do it exactly > right, etc. Doesn't matter if the tag gets approved or not, the proposal > process is formal. > "Informal" means "make it up as you need it." Or, as I said, ad hoc. > > -- > Paul > > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] motorcycle:scale
" Maybe I should eschew obfuscation." +1 LOL. We have enough problems with English here - no need to add Latin to our already strained conversations. I like the idea of the "informal" category but isn't that more or less the same as "proposed"? IMO, the main difficulty with keeping the Wiki updated is that editing it is tricky. I see grammatical errors all the time, for example, but don't want to get into a big conversation about any changes I make so I often just ignore them. And adding a proposal is simply too much work when I have so many other things I want to add to the map. I guess that's due to my own shortcomings. But then again, I imagine that issue keeps many mappers besides me from altering or adding things to it. Dave On Thu, Feb 7, 2019 at 6:11 PM Paul Allen wrote: > On Thu, 7 Feb 2019 at 10:52, Markus wrote: > >> >> Perhaps it would help though, if the status on the wiki page were more >> clear and prominent – maybe a different page colour and a status of >> 'informal' instead of 'in use' for those non-standard tags. >> > > Just to get into the spirit of things. };-) > > How about "impromptu" or "extempore" or "ad hoc" instead of informal? > When more widely > used we could change the status to "de facto." > > Maybe I should eschew obfuscation. > > -- > Paul > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal – RFC – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)
I like the proposal, Markus, but am confused by this statement: natural=peninsula is not intended for tagging coastal areas or coastal strips. What does it mean? Can you word it differently perhaps? Thanks for your efforts on this proposal. On Sat, Feb 2, 2019 at 12:10 AM Markus wrote: > Hello, > > Are there still any objections to or comments on this proposal? > Otherwise, i'd like to start voting in two weeks (if possible together > with the related proposal natural=isthmus). > > > https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:natural%3Dpeninsula > > Thank you all for your suggestions for improvement! > > Regards > > Markus > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Drain vs ditch
Sounds good, Eugene. I like those descriptions. On Wed, Jan 16, 2019 at 4:41 PM Eugene Podshivalov wrote: > =drain >> suggested: Use waterway >> <https://wiki.openstreetmap.org/wiki/Key:waterway>=drain for artificial >> waterways <https://wiki.openstreetmap.org/wiki/Waterways>, typically >> lined with concrete or similar, usually used to carry water for drainage >> or irrigation purposes. >> >> =ditch >> suggested: Use waterway >> <https://wiki.openstreetmap.org/wiki/Key:waterway>=ditch for simple >> narrow artificial waterways >> <https://wiki.openstreetmap.org/wiki/Waterways>, typically unlined, >> usually used to remove storm-water or similar from nearby land. Ditches >> are usually straight (as opposed to natural streams). They may contain >> little water or even be dry most of the year – to mark this intermittent >> <https://wiki.openstreetmap.org/wiki/Key:intermittent>=yes may be used. >> > > I don't know if that was done on purpose of by mistake but these > definitions are mixed up a bit. It is ditches that are used for irrigation, > not drains. > I would suggest to define them as follows. > > canal - large man-made open flow (free flow vs pipe flow) waterways used > to carry useful water for transportation, hydro-power generation, > irrigation or land drainage purposes. consider using waterway=ditch for > small irrigation or land drainage channels. consider using waterway=drain > for small lined superflous liquid drainage channels. > > drain - small artificial free flow waterways usually lined with concrete > or similar used for carrying away superflous liquid like rain water or > industrial discharge. consider using waterway=ditch for unlined channels > used to drain nearby land. consider using waterway=canal for large unlined > land drainage channels. > > ditch - small artificial free flow unlined waterways used for irrigating > or draining land as well as for deviding land. consider using > waterway=canal for large irrigation or land drainage channels. consider > using waterway=drain for lined superflous liquid drainage channels. > > No need to introduce any new tags. > > Eugene > > ср, 16 янв. 2019 г. в 05:12, Warin <61sundow...@gmail.com>: > >> On 16/01/19 11:53, Graeme Fitzpatrick wrote: >> >> >> On Wed, 16 Jan 2019 at 10:28, Dave Swarthout >> wrote: >> >>> >>> Although the 1st definition sort of agrees with your usage, the common >>> definition in the U.S. is closer to the other two. There are several other >>> definitions given but most of them are similar to those two. So it will be >>> a bit confusing to use here in the U.S. >>> >> >> Now why does that amaze me! :-) >> >> irrigation channel: a passage >> <https://www.macmillandictionary.com/dictionary/british/passage> dug >> <https://www.macmillandictionary.com/dictionary/british/dug> in the >> ground <https://www.macmillandictionary.com/dictionary/british/ground_1> >> and used <https://www.macmillandictionary.com/dictionary/british/used> >> for bringing >> <https://www.macmillandictionary.com/dictionary/british/bring> water >> <https://www.macmillandictionary.com/dictionary/british/water_1> to land >> <https://www.macmillandictionary.com/dictionary/british/land_1> in order >> <https://www.macmillandictionary.com/dictionary/british/order_1> to make >> <https://www.macmillandictionary.com/dictionary/british/make_1> plants >> <https://www.macmillandictionary.com/dictionary/british/plant_1> grow >> <https://www.macmillandictionary.com/dictionary/british/grow> >> >> >> >> OSM gives a distinction between river and stream. >> There should be a similar distinction between 'drain' etc. >> It should not be base on the flow of water as that could be hard to >> determine - especially if the water is off when mapping. >> >> For example, 'a drain can be easily stepped over'? >> ___ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Trailhead tagging
Your proposal looks good. I would vote "yes" on it. On Wed, Jan 16, 2019 at 4:28 PM Peter Elderson wrote: > I made a concept wiki page: > https://wiki.openstreetmap.org/wiki/Tag:trailhead > I think it fits the outcome of this discussion. If not, feel free to > comment. > > I don't want to change the earlier proposal, it is a step further than my > concept tagging page which just documents existing practice. > > > Vr gr Peter Elderson > > > Op di 15 jan. 2019 om 00:41 schreef Dave Swarthout < > daveswarth...@gmail.com>: > >> Kevin said: >> I'm therefore going to stick with 'designated or customary place to >> begin or end a trip on a trail.' >> >> Me too. I've mapped many such trailheads in Alaska and almost everybody I >> know would recognize the term trailhead as meaning a point of access to a >> path or trail. It's fine to add other details, like parking, toilets, >> registration facilities, etc. separately. I haven't followed this thread >> carefully, so can't speak to the TOP situation fully but I do know a >> trailhead when I see it on a map or otherwise. >> >> Dave >> >> On Tue, Jan 15, 2019 at 6:16 AM Graeme Fitzpatrick >> wrote: >> >>> >>> On Tue, 15 Jan 2019 at 09:04, Tod Fitch wrote: >>> >>>> >>>> Guess: Someone found it on the trail and figured it would be easier for >>>> the person missing it to find it hanging from the sign than some place >>>> along miles of trail. >>>> >>> >>> Bit of a problem when you've got to walk back the 65 klm looking for it! >>> >>> Thanks >>> >>> Graeme >>> ___ >>> Tagging mailing list >>> Tagging@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/tagging >>> >> >> >> -- >> Dave Swarthout >> Homer, Alaska >> Chiang Mai, Thailand >> Travel Blog at http://dswarthout.blogspot.com >> ___ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Creating shop=caravan
I appreciate your efforts on this, Graeme, believe me. However, seeing as motorhome and recreational_vehicle are so similar, I would use motorhome as a top-level tag with RVs being a special type of motorhome and have a separate shop=mobile_home page. Then all bases are covered. Mobile_home covers the odd case of the wheeled structure that is usually installed semi-permanently in a trailer park (see proposed feature for this https://wiki.openstreetmap.org/wiki/Proposed_features/Trailer_Park) or similar neighborhood. Note that on that page for anenity=trailer_park, they state: "As an amenity, this makes sense for truly mobile homes (aka recreational vehicles aka caravans". However, that definition should be changed to match our new definitions should you proceed along the path we're discussing. Confusion in terminology rears its ugly head on that page as well. LOL Also, if this split was to be adopted, how best then to differentiate a recreational_vehicle (powered, suitable for camping, but not a large motorhome) from the larger class of motorhomes? Good question. Maybe we could just assume that RVs are also motorhomes and let it go at that. On Wed, Jan 16, 2019 at 8:55 AM Graeme Fitzpatrick wrote: > OK, so after taking in everybody's thoughts & comments (thanks! :-)), I've > come up with: > > https://wiki.openstreetmap.org/wiki/Tag:shop%3Dcaravan > > https://wiki.openstreetmap.org/wiki/Shop%3Dmotorhome > > https://wiki.openstreetmap.org/wiki/Shop%3Drecreational_vehicle > > How's that? > > As always, all comments welcomed! > > Thanks > > Graeme > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Drain vs ditch
Graeme, I like the definitions you posted but why add "channel" to the list? When I think of a channel I think of a shipping lane or a dredged channel where ships with deeper drafts can pass through shallow water. From my online dictionary: 1. the bed of a stream, river, or other waterway. 2. Nautical: a navigable route between two bodies of water. 3. the deeper part of a waterway. Although the 1st definition sort of agrees with your usage, the common definition in the U.S. is closer to the other two. There are several other definitions given but most of them are similar to those two. So it will be a bit confusing to use here in the U.S. but it's not a huge problem if it appears in the Wiki list of definitions. On Wed, Jan 16, 2019 at 7:08 AM Graeme Fitzpatrick wrote: > > > On Tue, 15 Jan 2019 at 23:28, Eugene Podshivalov > wrote: > >> The confusion is mainly in the difference between irrigation canals vs >> irrigation ditches and drainage diches vs drains. >> >> In practice wide irrigation channels are called canals whereas small ones >> are called diches and people tend to tag them as such. >> This tendency is enforced by the fact that canals and diches are rendered >> in difference size. >> IMO there is no problem here, we should just document this usage properly. >> >> Drainage diches and drains are confused simply because of their identical >> definition on the waterway wiki page >> https://wiki.openstreetmap.org/wiki/Key:waterway >> drain - An artificial free flow waterway used for carrying superfluous >> water like storm water... >> ditch - An small artificial free flow waterway used for carrying >> superfluous water along paths or roads for drainage purposes >> > > So, would we all be happy with redoing the various wiki pages along these > lines: > > =canal: > current: Use waterway <https://wiki.openstreetmap.org/wiki/Key:waterway>= > canal for man-made *open flow* (free flow vs pipe flow) waterways > <https://wiki.openstreetmap.org/wiki/Waterways> used to carry useful > water for transportation, hydro-power generation or irrigation purposes. > > suggested: Use waterway <https://wiki.openstreetmap.org/wiki/Key:waterway> > =canal for large man-made *open flow* (free flow vs pipe flow) waterways > <https://wiki.openstreetmap.org/wiki/Waterways> used to carry useful > water, usually for transportation, but also for hydro-power generation or > irrigation purposes > > =drain > current: Use waterway <https://wiki.openstreetmap.org/wiki/Key:waterway>= > drain for artificial waterways > <https://wiki.openstreetmap.org/wiki/Waterways>, typically lined with > concrete or similar, used to carry superfluous water like storm water or > grey-discharge. > > suggested: Use waterway <https://wiki.openstreetmap.org/wiki/Key:waterway> > =drain for artificial waterways > <https://wiki.openstreetmap.org/wiki/Waterways>, typically lined with > concrete or similar, usually used to carry water for drainage or > irrigation purposes. > > =ditch > current: Use waterway <https://wiki.openstreetmap.org/wiki/Key:waterway>= > ditch for simple narrow artificial waterways > <https://wiki.openstreetmap.org/wiki/Waterways> used to drain nearby > land, to remove storm-water or similar. Ditches are usually straight (as > opposed to natural streams). They may contain little water or even be dry > most of the year – to mark this intermittent > <https://wiki.openstreetmap.org/wiki/Key:intermittent>=yes may be used. > > suggested: Use waterway <https://wiki.openstreetmap.org/wiki/Key:waterway> > =ditch for simple narrow artificial waterways > <https://wiki.openstreetmap.org/wiki/Waterways>, typically unlined, > usually used to remove storm-water or similar from nearby land. Ditches > are usually straight (as opposed to natural streams). They may contain > little water or even be dry most of the year – to mark this intermittent > <https://wiki.openstreetmap.org/wiki/Key:intermittent>=yes may be used. > > New category > =channel > Use waterway <https://wiki.openstreetmap.org/wiki/Key:waterway>=channel for > small man-made *open flow* waterways > <https://wiki.openstreetmap.org/wiki/Waterways> used to carry useful > water, usually for irrigation purposes. Channels are usually straight, but > can be either lined or unlined. > > Would something like that clarify matters? > > Thanks > > Graeme > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Trailhead tagging
Kevin said: I'm therefore going to stick with 'designated or customary place to begin or end a trip on a trail.' Me too. I've mapped many such trailheads in Alaska and almost everybody I know would recognize the term trailhead as meaning a point of access to a path or trail. It's fine to add other details, like parking, toilets, registration facilities, etc. separately. I haven't followed this thread carefully, so can't speak to the TOP situation fully but I do know a trailhead when I see it on a map or otherwise. Dave On Tue, Jan 15, 2019 at 6:16 AM Graeme Fitzpatrick wrote: > > On Tue, 15 Jan 2019 at 09:04, Tod Fitch wrote: > >> >> Guess: Someone found it on the trail and figured it would be easier for >> the person missing it to find it hanging from the sign than some place >> along miles of trail. >> > > Bit of a problem when you've got to walk back the 65 klm looking for it! > > Thanks > > Graeme > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Creating shop=caravan
I could live with two pages. A shop=caravan and a shop=recreational_vehicles cross-referenced to one another. It will be clear from the description that such recreational_vehicles contain kitchens, bathrooms, living quarters, and are not towed while the caravan page can specify the same but be restricted to towed, non-powered trailers. People on both sides of the ocean will have trouble with one or the other (both?) definitions but I don't see any other way through this semantic stalemate. Now, if we could only get rid of tourism_caravan_site and replace it with tourism=campground. Sigh. That'll never happen but it should. On Tue, Jan 15, 2019 at 6:14 AM Graeme Fitzpatrick wrote: > On Tue, 15 Jan 2019 at 08:50, Paul Allen wrote: > >> >> RV may not be only American, but it's still not UK English. >> > > Of course, you are correct Paul, I was forgetting for a moment that OSM is > supposed to be British English throughout (although we all know that that's > not really true!). > > Minor technicality really - main page stays as =caravan, secondary page/s > as =recreational_vehicles etc with a description & see shop=caravan. > > As far as I can see, that should cover everything, shouldn't it? > > Thanks > > Graeme > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Creating shop=caravan
Round and round we go and ne'er the twain shall meet. Mobile home simply will not work in this use case. Nobody camps or travels from place to place in a mobile home. On Mon, Jan 14, 2019 at 7:01 PM Paul Allen wrote: > On Sun, 13 Jan 2019 at 22:08, Graeme Fitzpatrick > wrote: > >> Wow, so much for me naively thinking that caravan was a universal word! >> Should know better by now :-) >> > > Yeah, where are the camels? It's not a proper caravan without camels. > > Have a question about searching though, which was raised previously. You >> have a place that deals in both (self-propelled) "motorhomes" & also >> (towed) "caravans", & it's tagged as a shop=caravan, with caravan=yes & >> also motorhome=yes (ignoring the exact wording for the moment). >> > > If you search for motorhome, will it be found because the details include >> motorhome=yes, or would you have to search for caravan, because it's tagged >> as a shop=caravan? (Sorry, I know that's badly worded but can't think of a >> better way of putting it) >> > > Having thought about it some more, and using shop=mobile_home as the main > tag (I know you > don't like it, but I do), then > mobile_home:sells=static_caravan;touring_caravan;motor_home. Yes, > I just mixed UK and US terms there, but it was about the best I could come > up with on a first > attempt (no doubt we will spend weeks arguing over those). Maybe we ought > to have > "caravan" and "static_caravan." > > So mobile_home appears to cover it. > > > Not really, sorry > > https://en.wikipedia.org/wiki/Mobile_home: "A *mobile home* (also > *trailer*, *trailer home*, *house trailer*, *static caravan*, *residential > caravan*) is a prefabricated > <https://en.wikipedia.org/wiki/Prefabrication>structure, built in a > factory on a permanently attached chassis before being transported to site > (either by being towed or on a trailer). Used as permanent homes > <https://en.wikipedia.org/wiki/Home>, or for holiday or temporary > accommodation, they are left often permanently or semi-permanently in one > place" > > Nothing in that excludes touring caravans. "Used as permanent homes *or* > for holiday > or temporary accommodation." "The are left *often* permanently [,..] in > one place." It may imply > that the term most commonly refers to static caravans but doesn't > explicitly exclude RVs, > touring caravans, etc. > > Also, from the second paragraph of https://en.wikipedia.org/wiki/Motorhome > "Motorhomes" are part of the much larger associated group of *mobile > homes* which includes > *caravans, *also known as tourers, and static caravans. > > Not that anyone should ever take Wikipedia as gospel for anything, but > that accords well with > (British) English definitions of "mobile" and "home." You can live in it > (home) and you can > move it around (mobile). "Motor home" excludes towed caravans and static > caravans (no motor) and > really only includes RVs and similar self-propelled vehicles. > > -- > Paul > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Creating shop=caravan
Americans would call them travel trailers, or camper trailers, and I would also categorize fifth-wheel campers as trailers, despite their sometimes enormous size, because they are pulled by a separate vehicle. Paul wrote earlier: In the US the term RV is a blanket term covering self-propelled, trailers and all other sub-categories To continue exploring that suggestion, we could create a new top-level tag, say shop=recreational_vehicle, or shop=rv, further characterize it using sells=trailed;self_propelled or some similar term, and then go on to flesh out the details using other sub-tags as previously suggested. Recreation_vehicle covers all the bases, is newer a term than caravan so perhaps less "loaded" with historical baggage, and would work best for the country within which the lion's share of such vehicles are bought and sold. Dave On Mon, Jan 14, 2019 at 10:41 AM Tod Fitch wrote: > > > On Jan 13, 2019, at 7:27 PM, Graeme Fitzpatrick > wrote: > > > > So what do you call "little houses on wheels that are towed behind your > car to stay in when you go on holidays"? :-) > > > > Are they just "trailers" > > > > Thanks > > > > Graeme > > “Travel trailers”. > > A generic plain “trailer” is probably for cargo or hauling your ATV, > snowmobiles or “dirt bikes”. > > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Creating shop=caravan
Nope, a mobile home is not the same as an RV or travel_trailer. Have a look at the illustrations on the Wikipedia page. It is, as the Wikipedia definition says, a prefabricated structure meant for permanent living. It has wheels, hence the mobile part of its name but it's moved very infrequently, sometimes only from the factory to its location inside of a, here's another American term, trailer park. An aside: As I consider this thread and the problems we're having with terminology I came to the realization that most countries don't have such things as we do in the U.S. Some of the motorhomes you see on American highways are behemoths based on a full-size bus chassis, powered by big rear-mounted diesel engines. I'd be willing to bet that no other country has anything even approaching the sheer size of these things. And they are quite common here. And are they expensive? Yep. 100 to 200K USD and up. Anyway, how best to describe the plethora of such vehicles, in the U.S. especially where they are so common, in one word? The term motorhome fits such monsters and works for many other smaller vehicles like your garden variety Winnebagos and extended van conversions but cannot describe unpowered trailers or, in British vernacular, caravans. Where do we go from here? On Mon, Jan 14, 2019 at 6:43 AM Warin <61sundow...@gmail.com> wrote: > On 14/01/19 09:07, Graeme Fitzpatrick wrote: > > Wow, so much for me naively thinking that caravan was a universal word! > Should know better by now :-) > > On Sun, 13 Jan 2019 at 21:58, Paul Allen wrote: > > > >> However, there does appear to be a better term. From >> https://en.wikipedia.org/wiki/Motorhome >> (the bold emphasis is mine): >> >> Motorhomes are part of the much larger associated group of *mobile homes* >> which includes >> caravans, also known as tourers, and static caravans. >> >> So mobile_home appears to cover it. >> > > Not really, sorry > > https://en.wikipedia.org/wiki/Mobile_home: "A *mobile home* (also > *trailer*, *trailer home*, *house trailer*, *static caravan*, *residential > caravan*) is a prefabricated > <https://en.wikipedia.org/wiki/Prefabrication>structure, built in a > factory on a permanently attached chassis before being transported to site > (either by being towed or on a trailer). Used as permanent homes > <https://en.wikipedia.org/wiki/Home>, or for holiday or temporary > accommodation, they are left often permanently or semi-permanently in one > place" > > > It would cover those things that slide in and out of utility vehicles and > act as accommodation. > > I think the 'mobile home' is an acceptable term to cover the lot. Why is > it unacceptable? > The emphasise on 'permanent' I think is wrong, but there is enough > vagueness to accept that 'mobile' means mobile. > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Creating shop=caravan
Back to the caravan vs motorhome distinction for a moment. By the way, Martin's page was in regard to access, so it's not so relevant to this discussion except to acknowledge that the term motorhome is in existence. Graeme mentioned propulsion so I assumed we were talking about what in the U.S. would be called motorhomes. Maybe then two top-level tags are needed, as he suggested. One for caravans or trailers, another for powered motorhomes, aka RVs. The pages could be similar in tagging scheme but have differing subtags. Bu that seems both wasteful and will likely be confusing. We could distinguish between the two basic varieties, motorized or trailer in some other tag. Dave PS: Martin's idea about OSM v2.0. Good one, Martin! On Sun, Jan 13, 2019 at 3:51 PM Dave Swarthout wrote: > Warin, You're in Australia, right? When I was traveling in New Zealand I'm > pretty sure they called small motorhomes caravans. But maybe not. > > I have no personal knowledge of the word caravan. To me, it makes no sense > at all to label anything having wheels as a caravan when everyone knows a > caravan is a string of freight-hauling camels negotiating the Sahara. I say > that in jest but yet, here we are again getting fouled up with usages in > different countries. We are stuck with tourism=caravan_site as well. Nobody > in the U.S. would ever refer to a campground hosting RVs and camping > trailers as a caravan_site or caravan_park but in OSM, of course, we must > do just that. > > Anyway, my reply needn't be restricted to "caravans" or trailers. It's > merely an idea I wanted to mention. Just now, Martin replied with a page > about motorhomes. I'll take a look and get back to you. > > On Sun, Jan 13, 2019 at 3:36 PM Warin <61sundow...@gmail.com> wrote: > >> On 13/01/19 19:06, Dave Swarthout wrote: >> >> >Possibly a separate page again for shop=motorhome? (I think that would >> be a good coverall term?) >> >> I would prefer that but it's an American term. We might as well just stay >> with caravan. Plus, I do think the tag you're proposing could, with enough >> thought, be made to work for all types of recreational_vehicles/caravans. >> >> There is a difference. >> Caravans attach to a motor vehicle for moment. >> Motor homes/campers are self propelled. >> >> >> There was a thread just a while ago on this list discussing ti-lo's solo >> initiative to upgrade motorcycle=shop tagging. It was/is a sensible scheme >> that integrated the functions of dealer, parts shop and accessories shop by >> using subtags to make the distinctions. (See the Services section: >> https://wiki.openstreetmap.org/wiki/Tag:shop%3Dmotorcycle#Services_tags). >> His scheme was criticized because he didn't discuss it fully enough on this >> list but aside from that, I liked the idea. The main tag and all subtags >> except those that already stand on their own, begin with the same keyword, >> motorcycle, and proceed from there, adding as much detail as desired or >> known. >> >> Hence, one might have >> caravan:parts=yes >> caravan:accessories=yes/no >> caravan:sales=yes/no >> caravan:type=type_a/type_b/type_c/fifth_wheel/trailer >> >> type? caravan:classification=* ? classifications could be local legal >> ones. Other things are descriptions .. and OSM has a tag for that. >> >> second_hand=yes/only >> caravan:propulsion=trailer/yes/solar_powered (wishful thinking) [also >> gas/diesel?] >> >> I say again, caravans are not self propelled - they need to be pulled >> along by something. >> Oxford Dictionary: A vehicle equipped for living in, typically towed by >> a car. >> Origin Late 15th century (in caravan (sense 2)): from French caravane, >> from Persian kārwān. The sense ‘covered horse-drawn wagon’ dates from the >> early 19th century. >> >> >> The caravan:types are well-known to anyone shopping for RVs (in America >> for sure but Europe or Asia, I dunno) but the tag is optional. Use it for >> fine-grained tagging, ignore it otherwise. >> >> >> In the UK smaller 'back' roads are narrow - Toyota Landcrusiers are seen >> as too wide, an American small Winabago is UK huge. >> >> >> Dave >> >> On Sun, Jan 13, 2019 at 1:01 PM Graeme Fitzpatrick >> wrote: >> >>> >>> >>> >>> On Sun, 13 Jan 2019 at 13:06, Dave Swarthout >>> wrote: >>> >>>> I'm assuming that this tagging scheme is also for a shop that sells >>>> only caravan parts and accessories but not caravans. >>>> >>> >>> No, I've tried to set
Re: [Tagging] Creating shop=caravan
Warin, You're in Australia, right? When I was traveling in New Zealand I'm pretty sure they called small motorhomes caravans. But maybe not. I have no personal knowledge of the word caravan. To me, it makes no sense at all to label anything having wheels as a caravan when everyone knows a caravan is a string of freight-hauling camels negotiating the Sahara. I say that in jest but yet, here we are again getting fouled up with usages in different countries. We are stuck with tourism=caravan_site as well. Nobody in the U.S. would ever refer to a campground hosting RVs and camping trailers as a caravan_site or caravan_park but in OSM, of course, we must do just that. Anyway, my reply needn't be restricted to "caravans" or trailers. It's merely an idea I wanted to mention. Just now, Martin replied with a page about motorhomes. I'll take a look and get back to you. On Sun, Jan 13, 2019 at 3:36 PM Warin <61sundow...@gmail.com> wrote: > On 13/01/19 19:06, Dave Swarthout wrote: > > >Possibly a separate page again for shop=motorhome? (I think that would be > a good coverall term?) > > I would prefer that but it's an American term. We might as well just stay > with caravan. Plus, I do think the tag you're proposing could, with enough > thought, be made to work for all types of recreational_vehicles/caravans. > > There is a difference. > Caravans attach to a motor vehicle for moment. > Motor homes/campers are self propelled. > > > There was a thread just a while ago on this list discussing ti-lo's solo > initiative to upgrade motorcycle=shop tagging. It was/is a sensible scheme > that integrated the functions of dealer, parts shop and accessories shop by > using subtags to make the distinctions. (See the Services section: > https://wiki.openstreetmap.org/wiki/Tag:shop%3Dmotorcycle#Services_tags). > His scheme was criticized because he didn't discuss it fully enough on this > list but aside from that, I liked the idea. The main tag and all subtags > except those that already stand on their own, begin with the same keyword, > motorcycle, and proceed from there, adding as much detail as desired or > known. > > Hence, one might have > caravan:parts=yes > caravan:accessories=yes/no > caravan:sales=yes/no > caravan:type=type_a/type_b/type_c/fifth_wheel/trailer > > type? caravan:classification=* ? classifications could be local legal > ones. Other things are descriptions .. and OSM has a tag for that. > > second_hand=yes/only > caravan:propulsion=trailer/yes/solar_powered (wishful thinking) [also > gas/diesel?] > > I say again, caravans are not self propelled - they need to be pulled > along by something. > Oxford Dictionary: A vehicle equipped for living in, typically towed by a > car. > Origin Late 15th century (in caravan (sense 2)): from French caravane, > from Persian kārwān. The sense ‘covered horse-drawn wagon’ dates from the > early 19th century. > > > The caravan:types are well-known to anyone shopping for RVs (in America > for sure but Europe or Asia, I dunno) but the tag is optional. Use it for > fine-grained tagging, ignore it otherwise. > > > In the UK smaller 'back' roads are narrow - Toyota Landcrusiers are seen > as too wide, an American small Winabago is UK huge. > > > Dave > > On Sun, Jan 13, 2019 at 1:01 PM Graeme Fitzpatrick > wrote: > >> >> >> >> On Sun, 13 Jan 2019 at 13:06, Dave Swarthout >> wrote: >> >>> I'm assuming that this tagging scheme is also for a shop that sells only >>> caravan parts and accessories but not caravans. >>> >> >> No, I've tried to set it up selling (dealer) as well as parts, repair & >> rental. Any other options you can think of, or better ways to word things? >> >> >>> Also, I see you've decided not to be specific about the type or style of >>> caravan sold. I would think caravan:style or caravan:class might be useful >>> to distinguish between type_a, type_c, fifth-wheel, trailer, etc. >>> >> >> Couple of people have suggested that & I've asked some questions about >> "how" but no feedback yet >> >> On Tue, 8 Jan 2019 at 07:54, Graeme Fitzpatrick >> wrote: >> >>> >>> Possibly something like caravan:type=caravan / motorhome / Winnebago / >>> camper trailer etc, but then you get to the problem of what is difference >>> between a camper van, motorhome & Winnebago? >>> >> >> motorised=yes / no? >> >> propulsion=towed / motorised? >> >> Possibly a separate page again for shop=motorhome? (I think that would be >> a good coverall term?) >> >> It's also, at least in the US, very common for
Re: [Tagging] Creating shop=caravan
>Possibly a separate page again for shop=motorhome? (I think that would be a good coverall term?) I would prefer that but it's an American term. We might as well just stay with caravan. Plus, I do think the tag you're proposing could, with enough thought, be made to work for all types of recreational_vehicles/caravans. There was a thread just a while ago on this list discussing ti-lo's solo initiative to upgrade motorcycle=shop tagging. It was/is a sensible scheme that integrated the functions of dealer, parts shop and accessories shop by using subtags to make the distinctions. (See the Services section: https://wiki.openstreetmap.org/wiki/Tag:shop%3Dmotorcycle#Services_tags). His scheme was criticized because he didn't discuss it fully enough on this list but aside from that, I liked the idea. The main tag and all subtags except those that already stand on their own, begin with the same keyword, motorcycle, and proceed from there, adding as much detail as desired or known. Hence, one might have caravan:parts=yes caravan:accessories=yes/no caravan:sales=yes/no caravan:type=type_a/type_b/type_c/fifth_wheel/trailer second_hand=yes/only caravan:propulsion=trailer/yes/solar_powered (wishful thinking) [also gas/diesel?] The caravan:types are well-known to anyone shopping for RVs (in America for sure but Europe or Asia, I dunno) but the tag is optional. Use it for fine-grained tagging, ignore it otherwise. Dave On Sun, Jan 13, 2019 at 1:01 PM Graeme Fitzpatrick wrote: > > > > On Sun, 13 Jan 2019 at 13:06, Dave Swarthout > wrote: > >> I'm assuming that this tagging scheme is also for a shop that sells only >> caravan parts and accessories but not caravans. >> > > No, I've tried to set it up selling (dealer) as well as parts, repair & > rental. Any other options you can think of, or better ways to word things? > > >> Also, I see you've decided not to be specific about the type or style of >> caravan sold. I would think caravan:style or caravan:class might be useful >> to distinguish between type_a, type_c, fifth-wheel, trailer, etc. >> > > Couple of people have suggested that & I've asked some questions about > "how" but no feedback yet > > On Tue, 8 Jan 2019 at 07:54, Graeme Fitzpatrick > wrote: > >> >> Possibly something like caravan:type=caravan / motorhome / Winnebago / >> camper trailer etc, but then you get to the problem of what is difference >> between a camper van, motorhome & Winnebago? >> > > motorised=yes / no? > > propulsion=towed / motorised? > > Possibly a separate page again for shop=motorhome? (I think that would be > a good coverall term?) > > It's also, at least in the US, very common for a dealer >> to sell one or the other, but not both. > > > But if we use a separate page, won't you have the same problem that you'll > only be able to find one or the other? > > As I mentioned earlier, if we had > > caravan:type=caravan / motorhome / camper_trailer > > would you be able to search for the type you want? > > So, any thoughts? > > Thanks > > Graeme > > PS How you going using Warin's suggestion to create pages? :-) > > > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Creating shop=caravan
I'm assuming that this tagging scheme is also for a shop that sells only caravan parts and accessories but not caravans. There are any such shops scattered around the U.S. Also, I see you've decided not to be specific about the type or style of caravan sold. I would think caravan:style or caravan:class might be useful to distinguish between type_a, type_c, fifth-wheel, trailer, etc. I think I saw some comments earlier in this thread about class. On Sun, Jan 13, 2019 at 9:13 AM Lorenzo Mastrogiacomi wrote: > Il giorno dom, 13/01/2019 alle 11.26 +1000, Graeme Fitzpatrick ha > scritto: > > > > > > > > On Sun, 13 Jan 2019 at 09:44, Lorenzo Mastrogiacomi < > > lomastr...@gmail.com> wrote: > > > Language links come from the shop=* page, probably because the page > > > name is wrong :) > > > Please use the Move action under More and enter the name > > > "Tag:shop=caravan". > > > > Thanks Lorenzo! > > > > Done, so page is now at > > https://wiki.openstreetmap.org/wiki/Tag:shop%3Dcaravan, > > but > > > > > Languages - how do I edit them all out? > > > > all the other languages are still listed? > > > > Thanks > > > > Graeme > > > > Ok, so I don't know why but I just added the type=value parameter to > the ValueDescription template and it looks good now. > > > > Lorenzo > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal – RFC – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)
Tomas, We just went through a whole discussion about mapping bays as polygons. (see https://lists.openstreetmap.org/pipermail/tagging/2018-November/040911.html) This is a similar one. I was one of the people who promoted converting nodes that describe bays into polygons in order to better represent their true size and provide better label placement. Now, after having to add boundaries to those areas of coastline, I can see the benefits of leaving the nodes as they are and allowing software to place the result labels as best it can. Many on this list didn't favor using multipolygons to outline bays either. Involving polygons does complicate subsequent mapping chores. For example, I was adding a National Park boundary in Alaska. I wanted to conflate it with coastline where I could. So I have this way, the boundary way, that is also shared with a peninsula, and also a portion of named ocean, the Chukchi Sea, a large "bay" of sorts, which is also a multipolygon. Each section of coastline/boundary must now be added separately to these three multipolygons! It's a ton of work. I stopped using multipolygons to map bays after that. I might use them on occasion to better "illustrate" peninsulas but I won't do that in an area where there's already multipolygon complexity present. As people pointed out in the last discussion, it makes for a ton of extra work and invites errors from novice mappers. I now agree with that view. Dave On Thu, Jan 10, 2019 at 2:56 PM Tomas Straupis wrote: > > 2019-01-10, kt, 09:06 Martin Koppenhoefer rašė: > > coding the geometry into the db does not necessarily mean creating polygons > > though. > > You could also store just 3 nodes and a hint that these are representing a > > polygon, to store a triangle (for example). > > Sorry, I did not get it. How saving only vertexes is better than > having a polygon (made out of those vertexes)? > > Full geometry is required to be able to calculate label positions on > all scales. For small scales this could be a simple curved line > (calculated from polygon geometry), for large scales it could be a lot > of labels placed/scattered on the same polygon geometry and > approximating (simplifying) such polygon too much would decrease > number of labels placed or labels would be placed outside of an object > which is even worse. > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Creating shop=caravan
Warin - I read through the documentation for Templates and the way it's used in Mediawiki applications like our Wiki is to define a piece of text, with or without photos, etc., as a reusable fragment that can be inserted in any page and if the original, the "template", is edited the changes propagate to all instances of the template in as many places as it appears. It's sort of like what used to be known as "boilerplate" in word-processors except its content is dynamic. Thanks for your clarification though. It motivated me to learn a bit more about the Wiki s/w I constantly complain about. LOL On Mon, Jan 7, 2019 at 3:32 PM Marc Gemis wrote: > Graeme, > > You might have to change the picture and the rendering icon in the > right "summary" bar. > > On Mon, Jan 7, 2019 at 8:22 AM Graeme Fitzpatrick > wrote: > > > > & here we go: https://wiki.openstreetmap.org/wiki/Shop%3Dcaravan :-) > > > > Known problems > > > > Languages - how do I edit them all out? > > > > service=parts has moved one box too far across > > > > Have to change the photo & (suggested) icon > > > > Wikidata reference > > > > Any & all other comments welcome! > > > > Seeing that apparently it's already been used 130 odd times, can I take > that we don't actually have to RFC & vote on it? > > > > Thanks > > > > Graeme > > > > > > On Mon, 7 Jan 2019 at 17:06, Graeme Fitzpatrick > wrote: > >> > >> > >> On Mon, 7 Jan 2019 at 11:12, Warin <61sundow...@gmail.com> wrote: > >>> > >>> This is what I do .. it works and leaves the original page alone... > >>> > >>> 1) get the "car" template > >>> On the page you want to copy Click on "edit Source" - Copy all of it > and paste it over to your your word processor as a new document. > >>> Exit out out this "Edit Source" without saving "cancel" I think is it > - so it stays the same. > >>> > >>> 2) edit the template > >>> Now in your word processor find and replace all the "car" and replace > with "caravan". Perform similar edits here - much easier than the editor > you may not be familiar with on the wiki. > >>> When your finished here ... > >>> > >>> > >>> 3) create the new page > >>> Type the title of the page you want to create in the wiki search box > ... > >>> It will come up with a suggestion to create the page you want .. click > on that and you have started to create the new page :) > >>> Copy all of the stuff you have on your word processor page over to the > new page (copy and paste) .. and save it ... Done. > >> > >> > >> Warin, that is fantastic! :-) > >> > >> Now you just have to write a page titled Creating pages, so everybody > can find it! > >> > >> Thanks > >> > >> Graeme > > > > ___ > > Tagging mailing list > > Tagging@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/tagging > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Creating shop=caravan
@Warin Can you illustrate or explain the differences between editing a "template" and editing a simple page? When you save your edited version of the new page does it become a template? On Mon, Jan 7, 2019 at 8:12 AM Warin <61sundow...@gmail.com> wrote: > This is what I do .. it works and leaves the original page alone... > > 1) get the "car" template > On the page you want to copy Click on "edit Source" - Copy all of it and > paste it over to your your word processor as a new document. > Exit out out this "Edit Source" without saving "cancel" I think is it - > so it stays the same. > > 2) edit the template > Now in your word processor find and replace all the "car" and replace with > "caravan". Perform similar edits here - much easier than the editor you may > not be familiar with on the wiki. > When your finished here ... > > > 3) create the new page > Type the title of the page you want to create in the wiki search box ... > It will come up with a suggestion to create the page you want .. click on > that and you have started to create the new page :) > Copy all of the stuff you have on your word processor page over to the new > page (copy and paste) .. and save it ... Done. > > On 07/01/19 11:23, Dave Swarthout wrote: > > Haha, Graeme. I am in the same boat when it comes to adding anything to > the Wiki. Welcome to the arcane world of Wiki editing. I don't have an > answer to your question. I only want to sympathize. > > Dave > > > > On Mon, Jan 7, 2019 at 5:35 AM Graeme Fitzpatrick > wrote: > >> Recently asked what to tag some things as, including a business selling >> caravans. >> >> On Sat, 29 Dec 2018 at 02:37, Philip Barnes wrote: >> >>> On Fri, 2018-12-28 at 16:36 +1000, Graeme Fitzpatrick wrote: >>> >>> >>> & yards dedicated to caravan sales? I can find shop=car >>> https://wiki.openstreetmap.org/wiki/Tag:shop=car, which says it's a >>> place that sells cars, buses or trucks. Perhaps shop=caravan? >>> >>> >>> Shop=caravan has over 100 uses, so why not? >>> >> >> With fear & trepidation :-) I am about to try & create a page >> shop=caravan, then put it up for further discussion. >> >> I know this has been discussed before, but I'm still unclear on the >> details (& from previous discussions, a lot of other people are as well :-() >> >> The page would be fairly similar to shop=car >> https://wiki.openstreetmap.org/wiki/Tag:shop%3Dcar, so that sounds like >> a good basis to start with. >> >> If I just open that page, "Edit source", change value=car to >> value=caravan, then save that, I'm fairly sure that will create a >> shop=caravan page ready for further editing, but will the original shop=car >> page still exist? >> >> Is there a better way to create a new page? >> >> > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Creating shop=caravan
Haha, Graeme. I am in the same boat when it comes to adding anything to the Wiki. Welcome to the arcane world of Wiki editing. I don't have an answer to your question. I only want to sympathize. Dave On Mon, Jan 7, 2019 at 5:35 AM Graeme Fitzpatrick wrote: > Recently asked what to tag some things as, including a business selling > caravans. > > On Sat, 29 Dec 2018 at 02:37, Philip Barnes wrote: > >> On Fri, 2018-12-28 at 16:36 +1000, Graeme Fitzpatrick wrote: >> >> >> & yards dedicated to caravan sales? I can find shop=car >> https://wiki.openstreetmap.org/wiki/Tag:shop=car, which says it's a >> place that sells cars, buses or trucks. Perhaps shop=caravan? >> >> >> Shop=caravan has over 100 uses, so why not? >> > > With fear & trepidation :-) I am about to try & create a page > shop=caravan, then put it up for further discussion. > > I know this has been discussed before, but I'm still unclear on the > details (& from previous discussions, a lot of other people are as well :-() > > The page would be fairly similar to shop=car > https://wiki.openstreetmap.org/wiki/Tag:shop%3Dcar, so that sounds like a > good basis to start with. > > If I just open that page, "Edit source", change value=car to > value=caravan, then save that, I'm fairly sure that will create a > shop=caravan page ready for further editing, but will the original shop=car > page still exist? > > Is there a better way to create a new page? > > Thanks > > Graeme > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] amenity=taxi vehicle type
In Alaska, which is largely roadless, there are countless air-taxis and many water-taxis. On Sun, Jan 6, 2019 at 7:45 AM Martin Koppenhoefer wrote: > > > sent from a phone > > On 5. Jan 2019, at 01:58, Joseph Eisenberg > wrote: > > Alternately, we could use amenity=motorcycle_taxi and amenity=pedicab(? is > this the British terminology?) > > > > there are also water taxis (with boats), Venice comes to mind, but there > are also others. > > https://en.m.wikipedia.org/wiki/Water_taxi > > Cheers, Martin > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] motorcycle tagging
I have been contacted at least twice by user:ti-lo about changing the tagging of several motorcycle shops I've added over the years. He is a bit of an evangelist for the new scheme yet has always been polite while asking to change my tags. Recently, I checked to see if the tags were documented in the Wiki and learned that the "new tagging" scheme aligned with his recommendations. I like the scheme and have always said, sure, go ahead never thinking that the Wiki had been modified by him (as user:Rtfm) to push the scheme he favors. I don't think it's good policy to discourage mappers from coming up with a new tagging scheme. However, such wholesale changes should be discussed fully here and perhaps elsewhere but, as someone else pointed out, trying to get anything approved by the tagging list is a long struggle that often ends in stalemate. I have often been frustrated by the endless deliberations that occur on this list when even a relatively small change in tagging has been suggested. Consequently, my opinion about what to do is mixed. Certainly, a full discussion is warranted before going ahead. Best, Dave On Sun, Jan 6, 2019 at 5:48 AM Warin <61sundow...@gmail.com> wrote: > On 06/01/19 06:51, Martin Koppenhoefer wrote: > > > > sent from a phone > > > >> On 5. Jan 2019, at 08:25, Warin <61sundow...@gmail.com> wrote: > >> > >> Not mandatory in OSM ... "Any tags you like". > > > > you can use any tags you like in your mapping, but that doesn’t imply > “changing” tags. It is one thing adding motorcycle:* tags, and another > removing “old style” tags. > > Or changing the value of a “standard key” from something well known to > something “new” (not established) (provided the well known value applies > according to common understanding). > > Thanks for reading the words and not adding to there meaning :) > > I too do not encourage changing current tags to some other tag. Only with > depreciated tags would I encourage there replacement with more current tag > use. > > > > > And it doesn’t imply changing the tagging recommendations in the wiki > unilaterally. You can do this on your user page, but not in the common > space. > > > > I agree with Allan’s proposition and ask him to set up a proposal. > > Rather than 'set up a proposal' I would ask the contributor (and that is > not Allen) to discuss the matter here. > > Possible problems are that the contributor does not have good English > skills and maybe reactant to enter into that problem area combined with the > problem of tagging. > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Trailhead tagging
Peter: " Mapping a trailhead node as I suggested does not stand in the way of more complex options. My idea: begin with the simplest common element which supports all the other options. " +1 On Wed, Jan 2, 2019 at 8:13 PM Peter Elderson wrote: > Sometimes it would, sometimes it would not. If the node actually > represents the start of the trail, it is already in the relation because it > is part of the way that belongs to the route. In the situation that a > trailhead node represents a named cluster of helpful facilities/amenities > in the vicinity of several trails or networks, you wouldn't want to add it > to all the relations, because a. it's not actually part of the routes and > b. maintenance of all the routes would be quite error-prone and not really > intuitive. > > A site relation has been suggested for the more complex trailheads. You > would include the node there, the parking(s), the information booth or > guide stands, maybe PT-stops, possibly the route relations you can access > from the site... > > Mapping a trailhead node as I suggested does not stand in the way of more > complex options. My idea: begin with the simplest common element which > supports all the other options. > > Op wo 2 jan. 2019 om 12:04 schreef Tobias Wrede : > >> Wouldn't it make sense to add the trail head (node) to a route relation >> with role=trail_head? >> >> Am 01.01.2019 um 12:54 schrieb Peter Elderson: >> > At this point, I settle for just requiring that it's a named location >> > visibly designated as access point for one ore more recreational routes. >> > >> > So just a node tagged highway=trailhead and name=> trailhead>. >> > >> > Which node? Well, if it's just the start with a name on a guidepost, >> > use the guidepost node. If it's an information board with the name, >> > use that. If there is a flagpole or a stele or say a statue of the >> > pioneer who walked it first, use that. If there is none of that, use >> > the location which presents itself naturally as a starrting point when >> > you get there. If there is no such location, then it's not a trailhead! >> > >> > Anything else: optional, map and tag as seems appropriate. >> > >> >> >> ___ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > > > -- > Vr gr Peter Elderson > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal – RFC – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)
Agree with Graeme. I like the illustration he shared too, "a cape can be found at the end of a peninsula (and, in my experience, often are) while you'll never see a peninsula at the end of a cape." The state of Florida is a peninsula as is India, at least by someone's definition. On Wed, Jan 2, 2019 at 4:42 AM Graeme Fitzpatrick wrote: > On Wed, 2 Jan 2019 at 02:01, Markus wrote: > >> >> Is the distinction of peninsulas from capes correct (see section See >> also)? >> > > I have concerns about the definition of peninsula that you've used "a > piece of land nearly surrounded by water and *connected to a larger land > area by an isthmus, that is a narrow strip of land*" > > I did see that definition, but most definitions of peninsula that I have > found don't mention the "narrow strip of land" eg peninsula: A piece of > land projecting into water from a larger land mass; cape: A piece or > point of land, extending beyond the adjacent coast into a sea or lake; a > promontory; a headland. > > Another good explanation, with some examples: > https://www.quora.com/Whats-the-difference-between-a-cape-and-a-peninsula-They-seem-to-have-different-definitions-that-are-in-practice-actually-the-same-thing. > As they put it "a cape can be found at the end of a peninsula. Peninsulas > are not found at the end of capes" > > I also give you Cape York Peninsula, > https://en.wikipedia.org/wiki/Cape_York_Peninsula which is a peninsula > terminating in Cape York - definitely no "narrow strips of land" involved! > :-) > > Thanks > > Graeme > > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] request for review: OSM wiki rewording of tourism=motel based on Wikipedia
LeTopographeFou wrote: > I also reached this conclusion some time ago but looking at how it is difficult to change something regarding tagging I stop authorizing myself thinking that such situation CAN be changed. However I'm not >affraid of such major change if it can bring enhancement. I'm ok to consider a proposal which would lead to the tourism=accomodation schema. I think such a page would be useful and I encourage you to write it as a proposal. It's going to be an uphill battle to promote a change in the basic tagging at this late date but an accommodation page would be a great start. As for mappers in countries where the distinction between types of accommodation is set in legal terms, they can just continue tagging the way it's always been done. On Wed, Jan 2, 2019 at 5:47 AM Graeme Fitzpatrick wrote: > > > On Tue, 1 Jan 2019 at 23:52, LeTopographeFou > wrote: > >> I'm ok to consider a proposal which would lead to the >> tourism=accomodation schema. >> >> But I think that whatever we do (new schema vs existing schema) an >> "Accomodation" wiki page (routing to hotel/motel/... tags) will be helpfull >> to today route to existing tags and maybe tomorrow explain the new schema. >> > > I agree with most of what has been said here, especially "the only > practical distinction today is the name on the front sign", however > >> Le 01/01/2019 à 03:23, Silent Spike a écrit : >> >> the current information there considers motels to be a subclass of hotels >> (so all motels are hotels, not all hotels are motels). >> >> On Mon, Dec 24, 2018 at 6:27 AM Allan Mustard wrote: >>>>> >>>>>> Local licensing authorities do not differentiate between them and >>>>>> they are regulated identically, >>>>>> >>>>> As I mentioned previously, in Australia at least, licensing > authorities *do* differentiate between them, in that a hotel is licensed > to sell alcohol, while a motel isn't. Granted, that doesn't effect > accommodation options, but a motel is not, strictly speaking, a hotel. > > Thanks > > Graeme > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] request for review: OSM wiki rewording of tourism=motel based on Wikipedia
Tobias wrote: "Now that several comments here indicate that the only practical distinction today is the name on the front sign I come to think that we could abandon the tag altogether." +1 I agree. We tend to "split hairs" in OSM, when in some cases it simply isn't worth the effort. These objects are just temporary accommodations that, granted, have varying characteristics. Here in Thailand, it's virtually impossible to differentiate between a guest_house and a hotel. And how should one tag facilities that label themselves as a "resort" (รีสอร์ท)? A better approach might (have been) to use a generic term like tourism=accommodation as a top level and then describe the facility more fully with subtags. Of course, we're pretty much stuck with the present imperfect tagging situation. Dave On Mon, Dec 31, 2018 at 10:18 PM Tobias Wrede wrote: > In Germany my experience is that actually most hotels in the cities charge > for parking. On the other hand you find very very few that call themselves > "motel". I can only think of one currently that does, and it is located > within a motorway rest area. The exception is the chain Motel One which is > a very typical _h_otel often located in city centers offering only limited > parking. > > When I think of a motel I always picture those with doors opening to the > car park from US movies. Now that several comments here indicate that the > only practical distinction today is the name on the front sign I come to > think that we could abandon the tag altogether. What value does it generate > for the data consumer if tourism=motel and tourism=hotel is all but the > same and practical distinction could for both be made by subtags > parking=y/n, parking:fee=y/n, etc? > > Tobias > > > Am 24.12.2018 um 01:12 schrieb Joseph Eisenberg: > > In the USA, we would also assume a motel offers free parking. Hotels may > charge extra for parking, especial if located downtown or next to an > airport. > > Is this also the case in Europe and Australia? > On Mon, Dec 24, 2018 at 8:55 AM Dave Swarthout > wrote: > >> "Today the main difference seems to be the sign out front. If a hostelry >> calls itself a motel, it is a motel. If it calls itself a hotel, it is a >> hotel. Local licensing authorities do not differentiate between them and >> they are regulated identically, so far as I can tell. I'd say the >> definition should be based on what is written on the sign on the hostelry." >> >> +1 >> >> That's my main criterion for tagging an accommodation as a motel. I >> agree with Volker's points and Allan's view on this. >> >> Happy Holidays >> >> Dave >> >> On Mon, Dec 24, 2018 at 6:27 AM Allan Mustard wrote: >> >>> Motel = MOtor hoTEL >>> >>> The major difference between a 'hotel" and a "motel" originally was the >>> configuration of the building with respect to parking. At a traditionally >>> designed motel, the cars are parked outside the units, which typically open >>> to the outdoors, not to a hallway, so that patrons of the motel may come >>> and go freely to their automobiles. Length of stay is immaterial. >>> >>> The first motels appeared on the Lincoln Highway in the 1920s, if memory >>> serves, and had little carports capable of accommodating a Model T >>> Ford-sized automobile next to a cabin (yes, the first motels featured >>> cabins, not rooms in a larger building). >>> >>> Then along came Motel 6, so called because it charged $6 per night back >>> in the day (it featured coin-operated TVs and you paid extra for everything >>> but the bed, bath, and four walls). Many Motel 6s had hallways, and that >>> changed the design, but they still catered to transients en route from >>> Point A to Point B. >>> >>> Today the main difference seems to be the sign out front. If a hostelry >>> calls itself a motel, it is a motel. If it calls itself a hotel, it is a >>> hotel. Local licensing authorities do not differentiate between them and >>> they are regulated identically, so far as I can tell. I'd say the >>> definition should be based on what is written on the sign on the hostelry. >>> These are my two cents' worth based on 30+ years of travel, including a few >>> cross-country trips across America as well as extensive on-ground travel in >>> Mexico, Russia, and central Europe. >>> >>> Cheers and Merry Christmas to all! >>> apm-wa >>> >>> >>> On Sun, Dec 23, 2018 at 4:33 AM bkil wrote: >>> >>>&g
Re: [Tagging] Trailhead tagging
I think tagging trailheads as nodes would work for the great majority of the trailheads I've seen over the years. The first node of a designated footway can be tagged as highway=trailhead, a name or other related tagging added to that, and other amenities such as parking lots, waste bins, toilets and the like can be tagged as nodes, or in some cases, relations. Many of the trailheads I've mapped have no other facilities associated with them, they are merely the beginning of a designated footway or hiking trail. In the definition in the Wiki, one could make it legal for relations to be tagged this way in order to accommodate those trailheads that encompass a range of amenities along with the trailhead itself. Dave PS: Happy New Year 2019 On Mon, Dec 31, 2018 at 9:52 PM Tobias Wrede wrote: > Hi eveyone, > > Am 21.12.2018 um 19:55 schrieb Peter Elderson: > > Well, in Nederland I'm through, got them all. To initiate a rendering > > on osm-carto the usage should increase by some 500+ (now on 1400+). I > > need Germany or Italy! > > While on vacation I have mapped trail heads in the US pretty much the > way Kenny has described it. I've never come across the trail head tag so > far. In the US trail heads I have encountered were often marked as such > having some signpost giving information on length, difficulty, > accessibility etc. And often there was a road sign saying "xyz trail > head". Often there is a single or very few trails departing there and > each trail only has one or two access points that are called a trail > head. (disclaimer: I am sure there are other situations but these are > the ones I have encountered while on vacation). > > In Germany, though, the concept of trail head is not so widely used for > hiking trails. Very often trails are interconnected forming a mesh and > are accessible from various locations. What we rather have are marked > parking lots called "Wanderparkplatz", i. e. "hiking parking lot". There > is even an official traffic sign: > > https://de.wikipedia.org/wiki/Datei:Zeichen_317_-_Wandererparkplatz,_StVO_1992.svg. > > The more fancy ones have a map of the surroundings showing all hiking > trails of the area, possibly with length, hiking duration and > difficulty. Often there is a waste bin, sometimes a pickinick table, > very often it's only a few parking spots off the road crossing a forest. > These hiking parking lots are very often not dedicated to a certain > trail, though. Often you find them in places where there are footways > but no marked or named hiking trails at all. > > As far as I see we don't currently designate these hiking parking lots > as such. They are just amenity parking connected to some paths/hiking > routes plus possibly having an information board mapped. I wouldn't be > opposed somehow tagging the Wanderparkplatz designation, not sure a > highway-tag would be right with the amenity, though. > > Having this said there are of course also some trail heads in Germany > that more fit to what I described for the US or what you might have in > the Netherlands. But they are the minority here I would say. > > all the best for the new Year > Tobias > > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal – RFC – place=peninsula
" I would think all of these should come under natural=x, & should be mapped as they are named: =headland, =cape, =peninsula, =promontory etc etc " +1 That's been my general practice as well. The designations of cape, point, peninsula, headland, etc., are all arbitrary and come from historical usage. On Fri, Dec 28, 2018 at 4:14 AM Graeme Fitzpatrick wrote: > > On Thu, 27 Dec 2018 at 19:05, Martin Koppenhoefer > wrote: > >> >> > Is there an upper cut-off where things stop being a peninsula? >> >> Hmmm ... not really. >> >> No indeed! When I did some looking into it, Europe can actually be > considered to be a peninsula off Asia! > > >> is there a difference to a “cape”? What about a promontory? Shall we >> distinguish these, and if yes how and according to which criteria? >> > > Same thing then applies to headland & isthmus? The natural=cape wiki makes > reference to See Also natural-isthmus (but the page doesn't exist!) & lists > natural=headland (also doesn't exist) as a Possible Tagging Mistake. Why? > > When I've looked at a few headlands I know, a couple of them are listed as > place=locality, name=Indian Head, which, to me, doesn't really ring true? > > I would think all of these should come under natural=x, & should be > mapped as they are named: =headland, =cape, =peninsula, =promontory etc etc > > Thanks > > Graeme > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Top up
"top up" is commonly used in Thailand for adding money to a cell phone balance. My bank's website, Kasikorn Bank, uses that exact term and offers a way to "top up" your phone online. On Thu, Dec 27, 2018 at 7:54 AM Tom Pfeifer wrote: > On 26.12.2018 19:05, bkil wrote: > > Please don't confuse top ups with refilling: > > > https://wiki.openstreetmap.org/wiki/Proposed_features/Refilling_a_purchased_drink > > No I don't confuse it. The refilling proposal is about refills without > additional charge. > To top-up a drink is purchasing a new one without wasting another clean > glass. > > > I think "top up" is standard terminology in the UK for increasing the > balance of prepaid mobile > > phone accounts. > > By which standard? I think it is marketing slang, as it makes no sense > semantically. > > > top_up:credit_card:‹brand›=yes;no > > As said, if the amount is pre-paid, it is not a credit card. It might be a > debit card because you > have to have the money in advance. > > tom > > _______ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal – RFC – place=peninsula
I would not disagree with the reasoning fur the use of either tag but have used natural=peninsula extensively in my Alaska mapping so I prefer going forward with that one. Dave On Thu, Dec 27, 2018 at 2:02 AM Markus wrote: > On Wed, 26 Dec 2018 at 19:23, Martin Koppenhoefer > wrote: > > > > Being this about a landform I would tend to prefer the natural key for > it, although the use of place isn’t defacto limited to man made places > (particularly locality) either. > > A peninsula is a land form, on the other hand, we're also using > place=* for islands, islets and continents (as well as oceans and > seas), which are also land forms. > > But i were fine with natural=peninsula too. The main thing for me is > that we can agree on one tag. > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] request for review: OSM wiki rewording of tourism=motel based on Wikipedia
"Today the main difference seems to be the sign out front. If a hostelry calls itself a motel, it is a motel. If it calls itself a hotel, it is a hotel. Local licensing authorities do not differentiate between them and they are regulated identically, so far as I can tell. I'd say the definition should be based on what is written on the sign on the hostelry." +1 That's my main criterion for tagging an accommodation as a motel. I agree with Volker's points and Allan's view on this. Happy Holidays Dave On Mon, Dec 24, 2018 at 6:27 AM Allan Mustard wrote: > Motel = MOtor hoTEL > > The major difference between a 'hotel" and a "motel" originally was the > configuration of the building with respect to parking. At a traditionally > designed motel, the cars are parked outside the units, which typically open > to the outdoors, not to a hallway, so that patrons of the motel may come > and go freely to their automobiles. Length of stay is immaterial. > > The first motels appeared on the Lincoln Highway in the 1920s, if memory > serves, and had little carports capable of accommodating a Model T > Ford-sized automobile next to a cabin (yes, the first motels featured > cabins, not rooms in a larger building). > > Then along came Motel 6, so called because it charged $6 per night back in > the day (it featured coin-operated TVs and you paid extra for everything > but the bed, bath, and four walls). Many Motel 6s had hallways, and that > changed the design, but they still catered to transients en route from > Point A to Point B. > > Today the main difference seems to be the sign out front. If a hostelry > calls itself a motel, it is a motel. If it calls itself a hotel, it is a > hotel. Local licensing authorities do not differentiate between them and > they are regulated identically, so far as I can tell. I'd say the > definition should be based on what is written on the sign on the hostelry. > These are my two cents' worth based on 30+ years of travel, including a few > cross-country trips across America as well as extensive on-ground travel in > Mexico, Russia, and central Europe. > > Cheers and Merry Christmas to all! > apm-wa > > > On Sun, Dec 23, 2018 at 4:33 AM bkil wrote: > >> I've made a major rewording of this tag. Please review and don't hesitate >> to comment or improve if I've mistakenly changed the meaning of the tag: >> >> >> https://wiki.openstreetmap.org/w/index.php?title=Tag%3Atourism%3Dmotel=revision=1755686=1561324 >> >> Source: based on Wikipedia and recent mapping experience: >> https://www.openstreetmap.org/changeset/65702446#map=9/47.1412/18.6632 >> >> It also looks like some have used the word motel for what should have >> been pensions and guest houses around here, I'll also fix these later. >> ___ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Trailhead tagging
I have tagged a few trailheads in Alaska using the tag highway=trailhead on a node followed by a tag for its name. I was under the impression that the tag was well-known and not in some sort of limbo. Other trailhead features if present, e.g., information boards or maps, I generally map separately. On Fri, Dec 21, 2018 at 9:36 PM Peter Elderson wrote: > Designated starting point for multiple routes into a nature area. There > is a designed marking pole or stele, information boards, seats or benches, > free parking space nearby. This one is in a small village: > > https://www.google.nl/maps/@52.4336993,6.834158,3a,75y,191.07h,84.64t/data=!3m6!1e1!3m4!1sby0P5NTeyqR3fyrgDNqCOA!2e0!7i13312!8i6656?hl=nl > > Here is another one, with emphasis on Parking. On the left behind the > parking is the actual access point to the trails. > > https://www.google.nl/maps/@51.6284198,5.0889629,3a,76.4y,32.53h,96.56t/data=!3m6!1e1!3m4!1sy3HdYWJ2zZ1rw1ozqJyrXw!2e0!7i13312!8i6656?hl=nl > > The operators are governmental bodies. They publish the lists on > recreation websites. Each province has its own list. VVV of course > lists/presents them as well. > > > These points are designed for trail access. > > Op vr 21 dec. 2018 om 14:31 schreef Andy Townsend : > >> Can you give a few examples of what trailheads are to you? There's a >> clearly defined American concept, it isn't not really used much in British >> English. Also what do you mean by "official" below - is there some kind of >> VVV list or similar? >> >> Best Regards, >> >> Andy >> On 21/12/2018 11:54, Peter Elderson wrote: >> >> I would like to revive the trailhead proposal, >> https://wiki.openstreetmap.org/wiki/Proposed_features/trailhead >> >> After discussions in the Dutch user community, a list of all Dutch >> trailheads was compiled and systematically entered as nodes tagged >> highway=trailhead, name=, tourism=information, >> information=board or map. Many trailheads were already present in OSM, >> there we just did some additional tagging. >> >> In the US, trailheads are all maintained on OSM by a national operator. >> Japan has lots of trailheads, I don't know how they are maintained. In >> Europe, no systematical OSM-tagging appears to take place, except for the >> Dutch base. >> >> I think it deserves a push. >> >> Any thoughts on the matter? >> >> -- >> Vr gr Peter Elderson >> >> ___ >> Tagging mailing >> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging >> >> ___ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > > > -- > Vr gr Peter Elderson > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Salumeria(it) / charcuterie(fr) / Wurstwaren (de) WAS Re: Can OSM become a geospacial database?
I have no idea how to tag a shop selling *salumeri* but I do know that shop=butcher and butcher=pork is totally wrong for a shop that sells cold cuts. Johnparis is quite right that a butcher is someone who slices and packages raw meat. In American English, the closest approximation for a shop selling assorted cold cuts is deli. It's very unlikely that a butcher would ever be involved in a deli operation. Dave On Thu, Dec 6, 2018 at 4:29 PM Johnparis wrote: > Cold cut, in American English anyway, is any sliced meat that is packaged > and sold chilled. Often pork based (ham and sausages like bologna are > popular) but also other meats like turkey. > > shop=butcher + butcher=pork is what the wiki suggests. > > I personally think of a butcher as someone who slices and packages raw > meat, but the wiki is clear that shop=butcher is for any sort of meat shop. > > John > > > On Thu, Dec 6, 2018 at 9:46 AM Martin Koppenhoefer > wrote: > >> >> >> sent from a phone >> >> On 5. Dec 2018, at 22:08, Sergio Manzi wrote: >> >> P.S.: ... but if I want my *salumeria *to show up on the map, I *have to* >> "*lie for the rendering*" and tag it as a shop=deli: but'I'm not happy >> at all... >> >> >> >> no you don’t have to, it will rather be counterproductive, because if >> everybody does like this they will never reach the limit that the rendering >> team will consider rendering them. >> >> A dictionary lookup suggests “cold_cut”, are there any native speakers >> who know what a salumeria is and if that term could work/apply ? >> >> 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 > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to map a sliding section of the Alaska Pipeline
Michael, Thanks for the suggestions. I'm on the road so can't reply in detail but I'll get back to you and the list before long. Dave On Sun, Nov 25, 2018 at 5:17 PM Michael Patrick wrote: > > ... There is a short section of the Trans-Alaska pipeline that crosses a > well-known fault line where it is attached to slides to allow lateral > movement in case of an earthquake. I split the pipeline way and added a > note to the section but that probably isn't visible to most data consumers. > Any ideas? > > OMG, Thank You Dave! > > I love ontological edge cases - and this is certainly good one. :-) > > I'd add something like "Deliberate Operator Movement" or "Directed > Movement" or some such to my description. These sort of joints are quite > common once one is cued to notice them. > > A friend of mine pointed on that a clear distinction was the pure > unidirectional ( along one path ) of rail-lines, whether it's road trains, > maglevs, or rail roads. There's no up/down or side ways component except > through a split, curve, or join in the track, where in the case of a > movable gantry there is usually a lifting, rotating, or conveying occurring > in addition to along the track axis. And as an additional note, regardless > of the type of point of contact ( rail, tire, magnetic ) the term for what > directs the travel is a 'track' ( unfortunately already occupied by the > road term ). > > > If it is moveable it is a gantry crane. A gantry per se can be > immobile, right? > > The immobile case ( like the fixed support for signs ) isn't that common, > as far as I could tell - in the sign case, the immobile case was more > commonly more simply called a 'bridge', probably because the spanning part > on even movable gantries and cranes is called a bridge. > > > Maybe not a rail line in the conventional sense, but I tagged an > (unfortunately disused) children's train in Ashgabat > https://www.openstreetmap.org/way/429019713 as a railway even though it > goes around and around, or used to, and has no destination. > > Another excellent case. Although it might be said t the origin and > destination merely have the same location, and differ along time and > direction path, , and as I noted, it's primary feature is as a conveyance, > not 'positioning' something for an action. Here the 'rails are rails' in > two uses ( > http://www.davidheyscollection.com/userimages/0001-dh-thornaby-roundhouse.jpg > ), but only one is the 'conventional sense' of a rail line - the other rail > is for positioning. > > Michael Patrick > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - boundary=aboriginal_lands
@Paul, Agree on the confusion and difficulty in using those blasted protect_class numbers. Let those issues be resolved in the boundary tag. I'm already tagging using protect_class along with the boundary tag and for insurance toss in the boundary:type tag. It's a lot of tagging that could be simplified immensely if we could just settle on one. IMO, boundary=aboriginal_lands says it all. On Sun, Nov 25, 2018 at 8:23 AM Paul Allen wrote: > On Sun, Nov 25, 2018 at 12:40 AM Alan McConchie > wrote: > >> >> Should we use the single tag boundary=aboriginal_lands for these areas? >> Or should we deprecate that tag (in other words, reject the proposal) and >> instead use boundary=protected_area + protect_class=24? >> > > My gut feeling is that protect_class is an abomination. > > Numbers are fine, where numbers are appropriate. Like the address of a > house, or the service > number for a bus, or the elevation of a peak. Protect_class is a > horrible, ugly mess. You cannot > easily figure out which value to use (first check with the WDPA, then try > to figure out from a gigantic > look-up table which value to use). To make it easy for mappers, instead > of just having a list of > possible values like "national_park," "historical_reserve" or whatever, > editors will need a look-up > table (not difficult to code, but unnecessary) from natural concepts like > "nature reserve" to 57 > (or whatever the number is). All data consumers like apps will need a > lookup table to translate from > number to concept so users can make sense of it (or put up with the > information that "You are now > entering a 37"). People using the query tool with the standard carto will > either have to then go through > the wiki to do a lookup or such a lookup will have to be built into the > code that handles queries. > > Gut feeling, late at night: anything has to be better than protect_class. > I must be missing something > since it presumably went through the approval process and passed, and > people actually use it, but > right now it looks like Satan conceived it to torment mappers before they > die. > > -- > Paul > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging Digest, Vol 110, Issue 135 Trans Alaska oil line
Hi Nick, No, I had not. But it's a good suggestion. On Sat, Nov 24, 2018 at 5:35 AM St Niklaas wrote: > Hi Dave, > > > Did you thought about movable=yes just as an extra value ? > > > Greetz > > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] How to map a sliding section of the Alaska Pipeline
This isn't a big issue but Warin's post about rails used to move big objects. Then someone replied with some illustrations of gantries and that triggered my curiosity. There is a short section of the Trans-Alaska pipeline that crosses a well-known fault line where it is attached to slides to allow lateral movement in case of an earthquake. I split the pipeline way and added a note to the section but that probably isn't visible to most data consumers. Any ideas? Photo here <https://www.dropbox.com/s/209xatghack8m35/Trans_Alaska_Pipeline_Denali_fault_shift.jpg?dl=0>: https://www.dropbox.com/s/209xatghack8m35/Trans_Alaska_Pipeline_Denali_fault_shift.jpg?dl=0 -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Using multipolygons to map bays in Alaska
Despite the remaining problem of just how best to map the Iarge Alaskan bay that started this conversation, it's been very interesting. For now, I'll just let it remain as a node and hope that a better label rendering solution for a water body as large as Cook Inlet comes along during my lifetime. I will decide whether to use multipolygons to show smaller bays and straits on a case by case basis. Thanks to all for your contributions. Alaska Dave On Sun, Nov 18, 2018 at 4:51 AM Paul Allen wrote: > On Sat, Nov 17, 2018 at 9:30 PM Kevin Kenny > wrote: > >> >> It is sounding as if Frederik and Christoph are willing to tolerate >> limited experiments as long as we mostly don't damage the coastline, >> > > Life would be so much easier if we had a sandbox. > > >> and keep our areas small enough not to break the toolchain. >> > > I was contemplating generalizing Cardigan Bay. Maybe a few dozen nodes. > But now you've made me > worry that it's not just the node count I should be concerned about but > also the size of the area > enclosed. Like I said, if only we had a sandbox... > > -- > Paul > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Using multipolygons to map bays in Alaska
That node too was left behind by mistake. I just now deleted it. The problem with using a way is that I can't see it. And I bet most current map products can't render it either. That someone with special cartographic skills can render it is good to know but it doesn't really help my situation. If those nodes can do the job you claim they for them, then someone needs to make it work that way on OSM, or OSMAnd. I don't know why Daniel made the choice to map that huge bay with multipolygons but calling it pollution isn't going to help matters. On Fri, Nov 16, 2018 at 6:26 PM Christoph Hormann wrote: > On Friday 16 November 2018, Dave Swarthout wrote: > > > > To answer Christoph's question about Chickaloon Bay and the node for > > the same bay, I simply forgot to delete the redundant node after I > > finished. Interestingly, the label for the new multipolygon fell only > > slightly to the east of the node so its placement was fairly > > accurate. However, in order to see the name on that node, one must > > zoom in so far that you have no idea whatsoever of the physical > > extent of the actual object. I know, that's a rendering issue. Still, > > the reason many of us enjoy mapping is so we can see the results of > > our labors somehow, preferably on a map, so it's a powerful incentive > > to do things in such a way that results in visualization. There is an > > enduring tension in the OSM world that we're always seeking to > > balance and this discussion is largely about where that balance lies. > > Yes, as already said i understand that and this is why i do not > primarily blame you or other mappers for using non-verifiable drawings > to map bays and straits but Daniel for incentivizing that for > ultimately selfish reasons. > > As a data user i am relatively relaxed on this because it is not a big > problem to reduce all these polygon drawings to a node before i use the > data. But i would not want to map or do data maintainance in an area > with such drawings. I see this as a problem of pollution control. Not > to litter the environment, not to pollute the air just because it is > convenient. > > > Also, sorry, I cannot see how representing a strait the size and > > importance of the Shelikof Strait (every Alaskan knows about this > > famous water passage) with a single way could work. A way is totally > > inadequate for such a task. Maybe that trick would work for a narrow > > strait that resembles a fjord but not for one as large as this one. > > Yes, i completely understand how this seems this way but i also know > that this is due to you not realizing how fairly easily you can > computationally assess the shape and the size of the street from a > single properly placed node. I will keep this case in mind for the > future as a good example to illustrate that. > > Note the current node: > > https://www.openstreetmap.org/node/561722 > > is of course not suitably placed. Correct position would be around > here: > > > https://www.openstreetmap.org/?mlat=57.9877=-154.0407#map=9/57.9877/-154.0407 > > -- > Christoph Hormann > http://www.imagico.de/ > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Using multipolygons to map bays in Alaska
s 'place a > single- or multi-line upright label on a point' needs the information. > You've given a very clever 'second best' approach to determining that > information when only a point is available - and I'm likely to find myself > using it because of the current state of the map data, so thank you for > that. > > Nevertheless, I think it would be much preferable to allow mappers to > communicate their intent. When mappers add a bay, inlet, gulf, fjörd, ... > to the map, they can be presumed to know what extent they would like the > object to have. What harm does it do if we give them a way to describe that > knowledge to others? Why the insistence on restricting the data model so > that we must use a brittle reconstruction technique rather than allowing > mappers to enter the extent of the object and data consumers to see it? > > The two arguments that I hear so far appear to amount to: > > - if any portion of an object's boundary is spatially indefinite, then > that object may not be represented as an area. > > Farewell to several counties and townships in the northern part of my > state, then. > > - carrying the data for bays is not scalable. > > In that case, we need to open a much broader discussion of general > categories of data that we need to exclude from OSM in order to manage the > size of the data base or the complexity of the computations. I surely don't > want to start seeing conflicts between better- and worse-mapped regions > over perceived inequities in the allocation of server resources! If instead > of data volume, the concern is the complexity of processing large objects, > then it would perhaps be better addressed by a rule that "no area feature > should exceed more than X km², have a mapped boundary length of y km, or > require more than z nodes for its representation" - and then work out how > we want to handle exceptions like countries, large islands, and large lakes > and seas. (That's then the right time to discuss what to do about bays, > straits, estuaries, and similar features.) The argument would also have to > distinguish between the cost of maintaining the data on the server - the > real OSM - and the cost of processing the data in the OSM-Carto rendering > chain - OSM's public face. If there's a way to have the information in the > actual OSM database but not in the main renderer, or have the pipeline > generalize it to a lower-cost but less informative form, that would be > better than discarding it entirely. > > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Using multipolygons to map bays in Alaska
@Christoph, Thanks for the feedback and the references to the previous discussions about this topic. The first reference to an earlier discussion on this list was particularly useful. From your email and that thread, I gather that you are opposed to mapping bays and straits as multipolygons. That comes through loud and clear. But there are others who disagree. I think both sides make valid arguments and I tend to agree with those who say go ahead and use multipolygons. It seems to me a better choice but that choice is not without its drawbacks. One I've already mentioned, and it was touched on in the thread as well, that of adding complexity to the map. You say that should be left to renderers to deal with, even imperfectly, in ways that are difficult for the non-specialist to understand. Okay, I'm fine with that. It's a ton of work to create multipolygons in order to force OSM to represent bays the way I would like to see them, so I'm not going to continue my practice of converting them to multipolygons. Nor will I try to "simulate" the Cook Inlet with an approximate area. a "labeling polygon", as you described it. I reckon I'll have to leave that to better future rendering software But the thread was interesting and I would like to make a few observations while I have your attention. Some have argued that defining the outside of a bay is difficult. I think that is not a big problem in my part of the world because I can access a very reliable source of geographic information via the USGS Topo map overlay. Most bays are fairly easy to outline with coastline and a simple way connecting the two extremes. Straits too are usually fairly easy to define spatially with the help of those maps. Straits are important geographic features and I think the use of multipolygons to define them is a useful methodology. Absolute accuracy is hard to attain but it doesn't matter all that much. What someone piloting a fishing boat in heavy weather wants to know is, am I in this bay or am I in the Shelikof Strait? If the Shelikof Strait (240 km long and 40-48 km wide), is represented by a mere node, I doubt that it would be possible to know one way or the other. However, because of its size and importance to Alaskans, I used the trick you advised against. I used segments of the Kodiak Borough boundary to define the north and south edges of the strait and then simply closed the area with straight way segments to create an area rather than adding hundreds of small sections of coastline to a large multipolygon created for the purpose. Not very accurate but better IMO than a node. I might go back and change that someday but at the moment I'm prepared to leave it as it is. There are so many other mapping chores to do in Alaska it boggles the mind. Cheers, Dave On Thu, Nov 15, 2018 at 6:11 PM Christoph Hormann wrote: > On Thursday 15 November 2018, Dave Swarthout wrote: > > [...] > > > > I was thinking it would be much easier and perhaps even better to > > just draw an approximate shape consisting of maybe 20 or 30 nodes, > > big enough to define the area and cause it to render, but easy to > > draw and without involving any multipolygons. The issue here is > > admittedly one I am pursuing to get these water bodies to render in a > > manner proportional to their size and I suspect that many will be > > against it on that basis alone. Still, I thought it worthwhile to > > mention my idea here and see what you think about it as a "shorthand" > > solution. > > I think it is good you bring this up because many mappers have been > doing exactly that without asking - See for example: > > https://www.openstreetmap.org/way/548210592 > https://www.openstreetmap.org/way/544856564 > > To put it right upfront: This is a bad idea. As you say the main > motivation for doing this is to make a bay show up in the map. > OSM-Carto has made the decision to incentivize this kind of mapping - > and as i like to point out to derivate from its self declared goal to > support mappers in consistent mapping towards steering mappers to map > in a way that is convenient for style developers. > > The 'polygons is universally the preferred way of mapping no matter if > verifiable or not' and 'way_area equals cartographic importance' > concepts have been meanwhile extended to natural=strait in OSM-Carto - > thereby not only incentivizing against mapping with nodes but also > against mapping with linear ways. > > To be fair: There are other map styles that do essentially the same so > it is not appropriate to exclusively blame OSM-Carto for this but it is > the only style that due to being rendered on OSMF infrastructure has a > true obligation not to do this. > > Mapping bays with polygons is always non-verifiable to a large extent. > Mapping bays with polygons
[Tagging] Using multipolygons to map bays in Alaska
Since the long thread I started about multipolygons [1 <https://lists.openstreetmap.org/pipermail/tagging/2018-October/040062.html>] is sort of winding down, I thought it best to start a new one to discuss something I've been doing since learning from that thread of the amazing power of the multipolygon data structure. Alaska has hundreds of bays and straits that have been added to OSM as nodes many years ago via an import (Tiger?). The nodes contain useful information but because they're only nodes cannot provide any visual representation of the size or extent of bigger bays and straits. I've begun to use multipolygon relations to show them more prominently using sections of coastline as the ways and then drawing a connecting way across the mouth of the bay or strait to complete the outer ring. This structure then defines the bay and when rendered it shows up nicely on the OSM slippy map. However, this method means that under certain circumstances some of those ways end up as members of several multipolygons. For example, the coastline might be part of a boundary, and in addition define a wooded or wetland area so it might be confusing to new mappers who might be put off by the complexities, as I was for a long time. That's one consideration. The other is the question about using this technique to map truly large bays like Cook Inlet. This is the reason I'm posting this question. Here is the first paragraph of the Wikipedia entry for the Inlet: Cook Inlet (Dena'ina: Tikahtnu) stretches 180 miles (290 km) from the Gulf of Alaska to Anchorage in south-central Alaska. Cook Inlet branches into the Knik Arm and Turnagain Arm at its northern end, almost surrounding Anchorage. On its south end merges with Shelikof Strait, Stevenson Entrance, Kennedy Entrance and Chugach Passage. So, I could mouse along the coastline adding pieces of it to a new relation until I have the entire Inlet surrounded, then draw a way from Elizabeth Island on the east side to the other side to define its mouth. I copy the tags from the existing node to the multipolygon and delete the node. But with a water body the size of Cook Inlet, that's a lot of work. I mapped Cook Inlet's Turnagain Arm [2 <https://www.openstreetmap.org/relation/8921978#map=9/61.1074/-149.5541>] the other day and it involved adding 14 ways as outers. How many will a multipolygon covering the entire Cok Inlet require? I was thinking it would be much easier and perhaps even better to just draw an approximate shape consisting of maybe 20 or 30 nodes, big enough to define the area and cause it to render, but easy to draw and without involving any multipolygons. The issue here is admittedly one I am pursuing to get these water bodies to render in a manner proportional to their size and I suspect that many will be against it on that basis alone. Still, I thought it worthwhile to mention my idea here and see what you think about it as a "shorthand" solution. Besides, I'm betting some other useful information will issue from the discussion. Dave [1] https://lists.openstreetmap.org/pipermail/tagging/2018-October/040062.html [2] https://www.openstreetmap.org/relation/8921978#map=9/61.1074/-149.5541 -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] رد: رد: New rag to draw node name with rotate angle
Martin's example illustrates what I've been doing with bays and straits in Alaska lately. Before I started doing this, all the bays in Alaska were marked with simple nodes that were imported many years ago from GNIS or somewhere. I hated that because they were all but invisible on most map renderings. Now, I split the coastlines that define the bay into ways which then become the boundaries of the bays, exactly as Mariusz Staniszewski did with the Bay of Biscay. Finally, after looking at the bay's extent on the USGS Topo map, I close the multipolygon with a way defining the end of the bay. I copy the GNIS node tags to the multipolygon and then delete the node. Now, the GNIS data, the names and extent show up beautifully on the OSM slippy map and presumably many other maps. Straits were not marked in any way, neither by nodes from GNIS or other mappers (Alaska has very few mappers and I'm the top OSM contributor there). Now, with the help of multipolygons, I have a way to define straits or narrows and to have the names render nicely. Take a look at the simple multipolygon for Sitkalidak Passage (id:8891978) here: https://www.openstreetmap.org/relation/8891978#map=14/57.2123/-153.2423 So, it seems that label rendering is a function of both how a place like a bay or strait is mapped as well as the realities of displaying labels in a readable fashion. I'm excited to have put into place a system that works quite nicely and doesn't duplicate any nodes to accomplish something I've wanted to do since I started using OSM. Cheers, Dave On Sun, Nov 11, 2018 at 3:14 AM Mateusz Konieczny wrote: > 10. Nov 2018 14:52 by hubais...@outlook.com: > > For OpenStreetMap rendrer: > > *https://www.openstreetmap.org/search?whereami=1=-1.406%2C0.220#map=3/-18.56/24.43 > <https://www.openstreetmap.org/search?whereami=1=-1.406%2C0.220#map=3/-18.56/24.43>* > > *Somalia, Madagasikara,Yemen **اليمن, Oman **عمان will be best if they > have a rotate angle* > > *India does not appear, Kynia has a chance to appear if Somalia has rotate > angle also Ghana have chance to appear if down vertically* > > > Note that Default map style on the OSM main page is not using place nodes > for rendering countries. > > > It is using relations like https://www.openstreetmap.org/relation/305138 > > > And, yes it is ignoring label role as it is a horrible idea. > > > -- > > > Different map styles require different label placement (as different map > styles display > > > different objects, may use labels in different languages, labels may use > different style > > > and it may be desirable to avoid blocking some objects with label - for > example standard map > > > may prefer label of coastal town to be placed on sea, map displaying sea > routes would prefer > > > to place town label inland). As result placement of this nodes is > optimized for specific map styles, > > > making them form of tagging for the renderer. ) > > _______ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag named group of named water areas?
Mateusz, The problem is how to get enough agreement and understanding to correct the Wiki. You can see how difficult that would be when even the regular contributors to the tagging list can't agree on what's correct. Imagine how overwhelmed new mappers must feel when they work on their first relations. Hell, until a few weeks ago, I tried never to get involved with any but the simplest ones. I have created many riverbank multipolygons and grouped a few geographic features, like the Groble ponds that began this thread, but even those uses involved lots of back and forth among us. Yes, the Wiki is far from perfect. That's a big reason we have these endless debates. But how should we go about fixing it? An additional issue for me is the difficulty of adding information to the Wiki. I've been a programmer in my earlier life so I'm not a newbie when it comes to looking at and interpreting code but the markup language for the Wiki is, IMHO, simply horrible. Someone once suggested I write up a Proposal for a tag I was thinking about. No thanks. I have better things to do with my time than to try to learn how that infernal formatting works. Best, Dave On Sun, Nov 11, 2018 at 3:21 AM Mateusz Konieczny wrote: > 8. Nov 2018 02:59 by daveswarth...@gmail.com: > > Another part of the problem is the Wiki that we treat as our bible. > > > I am not sure whatever anyone present on this mailing list is doing this. > In case that someone is doing it: remember that WIki is missing plenty of > documentation > and many parts are outdated or represent rather who was last editor rather > than reality. > > Anyway, I encourage everybody to improve problematic pages. > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Estimated values for height
You can also use height=* for both and add a "source:height=estimated / measured" tag with that to have a value that is usable by the apps and tools but still keeping the information that it was only estimated ! ;-) An excellent solution, Lionel On Fri, Nov 9, 2018 at 5:06 PM marc marc wrote: > look at the current values in height, you understand from their > round values that they are massively estimated. > > my preference is therefore to use height and make 2 changset > to put a changeset tag related to the source > of the measurement: measured <> estimated > > Le 09. 11. 18 à 10:57, Lionel Giard a écrit : > > You can also use height=* for both and add a "souce:height=estimated / > > measured" tag with that to have a value that is usable by the apps and > > tools but still keeping the information that it was only estimated ! ;-) > > > > > > Lionel > > > > > > > > Le ven. 9 nov. 2018 à 10:19, Dave Swarthout > <mailto:daveswarth...@gmail.com>> a écrit : > > > > There is already an est_width tag (Taginfo 77,000). I see no reason > > why you couldn't use est_height, which has over 1000 instances in > > Taginfo. > > > > Dave > > > > On Fri, Nov 9, 2018 at 3:58 PM Cascafico Giovanni > > mailto:cascaf...@gmail.com>> wrote: > > > > I'm going to import a small dataset of trees. Some tree heights > > are defined as "measured", some as "estimated". > > > > About estimated values, I've found a wiki definition only for > > width [1]: shall I > > derive an est_height tag, > > go for most popular taginfo solutions, > > simply assign an estimated value to height tag? > > > > > > > > [1] https://wiki.openstreetmap.org/wiki/Key:est_width > > ___ > > Tagging mailing list > > Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org> > > https://lists.openstreetmap.org/listinfo/tagging > > > > > > > > -- > > Dave Swarthout > > Homer, Alaska > > Chiang Mai, Thailand > > Travel Blog at http://dswarthout.blogspot.com > > ___ > > Tagging mailing list > > Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org> > > https://lists.openstreetmap.org/listinfo/tagging > > > > > > > > ___ > > Tagging mailing list > > Tagging@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/tagging > > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Estimated values for height
There is already an est_width tag (Taginfo 77,000). I see no reason why you couldn't use est_height, which has over 1000 instances in Taginfo. Dave On Fri, Nov 9, 2018 at 3:58 PM Cascafico Giovanni wrote: > I'm going to import a small dataset of trees. Some tree heights are > defined as "measured", some as "estimated". > > About estimated values, I've found a wiki definition only for width [1]: > shall I > derive an est_height tag, > go for most popular taginfo solutions, > simply assign an estimated value to height tag? > > > > [1] https://wiki.openstreetmap.org/wiki/Key:est_width > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag named group of named water areas?
water) > allways belong to the members and not any encompassing relation such as > relation:waterway. > man_made=pipeline looks like on of those tags I would always put on the > members, > not the relation. > > Richard > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag named group of named water areas?
Also agreed. I'm not saying anything about the route tag. We're talking about tags other than route or type, which actually set up the relation. The additional tags that describe the route or multipolygon either go on the relation or the ways depending on their scope, but not both. On Thu, Nov 8, 2018 at 5:31 PM Peter Elderson wrote: > And route=foot does not mean al the components are footpaths. > > Op do 8 nov. 2018 om 11:05 schreef Andy Townsend : > >> On 08/11/2018 01:59, Dave Swarthout wrote: >> > To my way of thinking, a tag in the relation implicitly applies to >> > every member of the relation. >> >> No. Think of a long-distance footpath - that may have an operator, or >> it may have tags that apply specifically to the footpath route. It may >> also run along a road for a short distance - it doesn't mean that the >> footpath "operator" is the "operator" of the road. >> >> Best Regards, >> >> Andy >> >> >> ___ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > > > -- > Vr gr Peter Elderson > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag named group of named water areas?
I totally agree, Andy. So yes, if someone has tagged the relation with an operator and in reality, there are different operators (or none) for some parts of the route, those parts should have tags to indicate the change. My illustrative case involves a pipeline that (AFAIK) has only one operator (oops, owner) so it's not the same situaiton. But don't hold me to specifics. I'm trying to illustrate a point and my choice of tag and value to do it may have been wrong. I just checked Wikipedia and the pipeline is owned by the Alyeska Pipeline Service Company so please substitute owner for operator just for the purposes of the illustration. At any rate, using my reasoning, if an operator or owner tag doesn't apply to the route as a whole, it should appear on the individual ways and not in the relation. However, for the TAPS, such items as owner apply to the entire route, just as do Wikidata and Wikipedia tags, substance, etc. IMO, those tags belong on the relation and are not necessary on the individual ways. Best, Dave On Thu, Nov 8, 2018 at 5:05 PM Andy Townsend wrote: > On 08/11/2018 01:59, Dave Swarthout wrote: > > To my way of thinking, a tag in the relation implicitly applies to > > every member of the relation. > > No. Think of a long-distance footpath - that may have an operator, or > it may have tags that apply specifically to the footpath route. It may > also run along a road for a short distance - it doesn't mean that the > footpath "operator" is the "operator" of the road. > > Best Regards, > > Andy > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag named group of named water areas?
Yves, " mapping a way is simpler than a relation for most." I totally understand that. In fact, in the first of those references, the opening statement is " Usually the pipeline is mapped just with simple ways".I think that's a valid approach for short pipelines but this thing is huge. Whoever created it used a relation for whatever reason and I think it was a good decision. Now, however, we're faced with mapping and understanding it. The Wiki hasn't been much help and, obviously, there is disagreement among member of this group as to what is right and proper. Trying to understand exactly what a relation is and how it relates to its constituent parts was, and is, the reason for my comments to this thread. It's been a very valuable thread for me because through it, I've learned a lot. The video put together by Adam Franco has completely revolutionized my mapping of complex boundaries and water bodies. this short tutorial. <https://youtu.be/x7SPb0JtheA> Thanks again, Adam Cheers, Dave On Thu, Nov 8, 2018 at 12:21 PM Yves wrote: > Dave, > Not that what you say doesn't make sense, cause it does. > However I just think that the wiki is not the bible (it's a wiki), > secondly OSM is not that square as it is made to be edited by hand. > Keep it simple here just means that mapping a way is simpler than a > relation for most. > Yves -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag named group of named water areas?
irst one is obvious but the second and third? What would a route of pipeline markers be? What about a route of pipeline stations? One wonders where these examples came from. An email list? Or are they just reasonable guesses made by someone who was pressed for time and wasn't very thorough in vetting the choices he left us? It's no wonder we're confused about pipeline routes. That said, I need to get back to my mapping projects. I've tried everything I can think of to justify my actions and it's wearing me out. I promise not to change any of your previously tagged ways on relations. You guys can continue to tag the ways on relations if you wish. I'll wait patiently for the day when map products fully understand what a relation is and can render it properly without tagging each and every member way. Respectfully, Dave On Thu, Nov 8, 2018 at 3:55 AM Paul Johnson wrote: > On Wed, Nov 7, 2018 at 2:07 PM Yves wrote: > >> Agreed with Martin here, I would be amazed that the name of a pipeline >> would contradict the name of one of its section being something else than a >> pipeline. >> >>> > I'm not super familiar with them compared to railroads, but similar > naming conventions exist. Branches and trunks often have differing names > while being part of the same overall pipeline. > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag named group of named water areas?
Thanks,
I added it to my styles and promise to try it soon.
Dave
On Wed, Nov 7, 2018 at 4:12 PM Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:
> Dave,
> reg. a rule for mkgmap: A simple approach would be to add a rule in the
> relation style so that the tag man_made=pipeline is added to all way
> members
> of the relation which don't already have a man_made tag:
> #pipelines
> type=route & route=pipeline
> {
> apply way {
> add man_made=pipeline;
> }
> }
> Maybe use set instead of add to catch cases like relation 3220256 where
> some
> long ways are tagged as man_made=cutline
> I leave it to you to find out how you can transfer the other tags like the
> name of the route relation. The default style contains samples for that.
>
> Gerd
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag named group of named water areas?
PS: Gerd and I are not at war here. We just don't agree on the correct way to proceed. In fact, I have had lots of help from him when developing maps for my Garmin and will need his help in the future, no doubt. Maybe to convince him to write the code in mkgmap to better "see inside" relations to dig out the details. I know for a fact that without a man_made=pipeline tag on those ways, my current style sheet won't find them and will be unable to render them. Unless I get help from Gerd. LOL On Wed, Nov 7, 2018 at 2:27 PM Dave Swarthout wrote: > It's true. Gerd and I have gone round and .around on this topic. Gerd has > tried to convince me that I should not remove any tags of the ways > contained in the existing Alaska pipeline relation and I'm convinced that > the only tags that belong on those ways are the ones that make that > particular way different from any other ways. Hence, tags like location, > and bridge, properly belong on the ways. Obviously, you can't include > bridge=yes and layer=1 in any top level relation. Those sorts of attributes > belong on the way and only on the way. I have tried to convince him that > any attribute or characteristic that applies to the pipeline in its > entirety, belongs on the relation and not on the pipeline way itself. It > doesn't hurt to have them there but it's unnecessary and I also argue, > having those duplicated tags makes maintaining the relation rather messy. > > I provided two examples from the Wiki and a part of a response earlier in > this thread from Kevin Kenny to support my argument that state that > individual ways in a multipolygon or relation should not be tagged unless > their characteristics require it. If you're working with a route=road and > the surface changes, you split the way and mark it so. Same with maxspeed > or number of lanes. The characteristics are those of the way, not the > entire route, and rightly belong only on the way. In the case of the > pipeline, tags like man_made=pipeline, substance=oil, operator, Wikipedia > and Wikidata tags, belong in the relation. The people who first added the > pipeline to OSM did it both ways, probably to guarantee that it would be > visible to OSM or other data consumers, but I don't know. > > I believe the people that cautioned us in the Wiki, people that I assume > know more about it than either Gerd or me, to add tags to a way contained > in a relation only when its characteristics or attributes are different > from the overall route characteristics. I take their meaning literally. > Gerd disagrees but gives no proof for his assertion. > > So there you have it. We're stuck. > > Dave > > > > On Wed, Nov 7, 2018 at 12:27 PM Gerd Petermann < > gpetermann_muenc...@hotmail.com> wrote: > >> Hi all, >> >> after reading the last comments in this thread I tried again to convince >> Dave that the rather special rules for multipolygon relations cannot be >> used >> for all types of relations, esp. not those with route=pipeline and that he >> should not remove tags like man_made=pipeline from ways of such a >> relation, >> see this long discussion: >> https://www.openstreetmap.org/changeset/64027881 >> >> I give up now because for me a type=multipolygon relation is something >> completely different and Dave insists that it is are not. Seems we are >> both >> frustated now :-( >> >> Gerd >> >> >> >> >> >> >> >> -- >> Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html >> >> ___ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > > > -- > Dave Swarthout > Homer, Alaska > Chiang Mai, Thailand > Travel Blog at http://dswarthout.blogspot.com > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag named group of named water areas?
It's true. Gerd and I have gone round and .around on this topic. Gerd has tried to convince me that I should not remove any tags of the ways contained in the existing Alaska pipeline relation and I'm convinced that the only tags that belong on those ways are the ones that make that particular way different from any other ways. Hence, tags like location, and bridge, properly belong on the ways. Obviously, you can't include bridge=yes and layer=1 in any top level relation. Those sorts of attributes belong on the way and only on the way. I have tried to convince him that any attribute or characteristic that applies to the pipeline in its entirety, belongs on the relation and not on the pipeline way itself. It doesn't hurt to have them there but it's unnecessary and I also argue, having those duplicated tags makes maintaining the relation rather messy. I provided two examples from the Wiki and a part of a response earlier in this thread from Kevin Kenny to support my argument that state that individual ways in a multipolygon or relation should not be tagged unless their characteristics require it. If you're working with a route=road and the surface changes, you split the way and mark it so. Same with maxspeed or number of lanes. The characteristics are those of the way, not the entire route, and rightly belong only on the way. In the case of the pipeline, tags like man_made=pipeline, substance=oil, operator, Wikipedia and Wikidata tags, belong in the relation. The people who first added the pipeline to OSM did it both ways, probably to guarantee that it would be visible to OSM or other data consumers, but I don't know. I believe the people that cautioned us in the Wiki, people that I assume know more about it than either Gerd or me, to add tags to a way contained in a relation only when its characteristics or attributes are different from the overall route characteristics. I take their meaning literally. Gerd disagrees but gives no proof for his assertion. So there you have it. We're stuck. Dave On Wed, Nov 7, 2018 at 12:27 PM Gerd Petermann < gpetermann_muenc...@hotmail.com> wrote: > Hi all, > > after reading the last comments in this thread I tried again to convince > Dave that the rather special rules for multipolygon relations cannot be > used > for all types of relations, esp. not those with route=pipeline and that he > should not remove tags like man_made=pipeline from ways of such a relation, > see this long discussion: > https://www.openstreetmap.org/changeset/64027881 > > I give up now because for me a type=multipolygon relation is something > completely different and Dave insists that it is are not. Seems we are both > frustated now :-( > > Gerd > > > > > > > > -- > Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag named group of named water areas?
Let me try to clarify what I'm saying again. Gerd writes: If we follow Daves idea one might create a relation combining a few things that have the same tag, e.g. all building=residential in a town, name it something like "residential buildings" and finally remove the tags from those buildings. I hope nobody thinks this would be a good idea. I m would never do anything like that. If you can follow my reasoning, you'll see that for the example you're using my argument would say that those ways that comprise the buildings would stay on those ways and not on the relation. That's' because the object "building" requires a way that is tagged specifically as a building and as such, according to my reasoning, properly belongs on the way and only on the way. If the buildings are part of a group that is an entity, like a university for example, then create a relation and place its name there along with whatever other tags apply to the university as a whole; owner, website, etc., and then add the building ways to it. The tags for the buildings, each with the tags that apply to it, be it office, dormitory, whatever, are placed on the way only and the buildings render as they do if even if they were not part of a relation. One must look a little closer to determine that they're part of something larger. Gerd also said: "I think Dave wants to use relations as a general method to remove redundancy. The idea is not new and I think there similar discussions before. I think one of the arguments against it was that many editors are not able to handle relations good enough, I fear this is still true. I think the same problem is on the consumer side' Not at all. Using relations properly could indeed reduce redundancy, and that was the goal of my editing of the Alaska pipeline, but my aim for starting this thread was to discuss relations and learn to use them better. Also, Gert mentioned rendering. Let me repeat what I said earlier in this thread about rendering. Rendering, while it's an important concern for all of us, really shouldn't be a part of this discussion. We're trying to learn how to best use a very powerful method of mapping a complex world. Whether or not something shows up on the map (is rendered) is not what I'm talking about here. On Sun, Nov 4, 2018 at 4:15 PM Gerd Petermann < gpetermann_muenc...@hotmail.com> wrote: > If we follow Daves idea one might create a relation combining a few things > that have the same tag, e.g. all building=residential in a town, name it > something like "residential buildings" and finally remove the tags from > those buildings. I hope nobody thinks this would be a good idea. > > Reg. the TAP pipeline (I was the complaining user that Dave mentioned): I > did not even know that something like a route=pipeline exists before I saw > that Dave removed the tags from the member way. The same seems to be true > for JOSM developers because the way is no longer rendered as a pipeline in > JOSM. > Well, that might be something that should be fixed in JOSM. > > I think Dave wants to use relations as a general method to remove > redundancy. The idea is not new and I think there similar discussions > before. I think one of the arguments against it was that many editors are > not able to handle relations good enough, I fear this is still true. I > think > the same problem is on the consumer side: > A renderer or routing app has to know which types of relations might > contain > information that has to be transferred to the members, it cannot do that > with a simple rule like "if a way is the member of a relation, copy all > attributes of the relation to the way". Just think about cases where a > highway is member of several route relations. > So, if one starts to remove tags from members because the relation repeats > the tag he has to make sure that this is a well established method. Not > sure > if this is the case for pipelines? > > > > > -- > Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html > > _______ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag named group of named water areas?
Mateusz wrote: "Both methods are not very easy but are necessary very rarely and it allows to avoid problematic "half of tags is here, half in this relation" that is highly problematic for mappers" I realize it can be done this way but it's a ton of work (quote: not very easy) compared to making one simple edit to tag the entire collection of ways. I simply cannot understand why anyone would prefer this method over the much easier one of merely adding or editing a tag in the relation. As for your comment: "half of tags is here, half in this relation"; frankly that problem wouldn't exist if people were tagging relations properly in the first place. On Sat, Nov 3, 2018 at 5:30 PM Mateusz Konieczny wrote: > 3. Nov 2018 00:00 by daveswarth...@gmail.com: > > To make matters worse, let's just say you misspelled the Wikipedia tag > value. You meant to write "wikipedia=en:Trans-Alaska Pipeline System" but > forgot to include the "en:" prefix. Back you go to your editor, editing all > 280 pieces again. That's why I say tagging it this way is a maintenance > nightmare. > > > (1) First method: download area with relation in JOSM, download all > relations members, > > use "select members" in relation listing menu. > > > -- > > > (2) It can be also relatively easily done with help of overpass turbo. > > > Search with overpass turbo wizard > > wikipedia="en:Trans-Alaska Pipeline System" global > > > results are in https://overpass-turbo.eu/s/DkY > One may use "Export" button to send this data to your editor. > > Both methods are not very easy but are necessary very rarely and it allows > to avoid > problematic "half of tags is here, half in this relation" that is highly > problematic for mappers. > > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag named group of named water areas?
I've been saying that I believe tagging that applies to an entire relation should be placed ONLY on the relation and NOT on the individual ways, UNLESS, there is some characteristic of the way that requires different tagging. I gave examples using the Trans Alaska Pipeline but this reasoning extends to other cases. Just now, I came across this statement in the Wiki concerning islands in a river system: "To map islands in a river you can use a multipolygon <https://wiki.openstreetmap.org/wiki/Relations/Multipolygon> relation and the island and the main river bank should be included in the relation. The main riverbank way (way 1 in image above) will have the role 'outer' and the way for the island (way 2 in image above) will have the role 'inner'. *When mapping with multipolygon relations do not tag the member ways with waterway=riverbank as well - this is wrong. Member ways should be untagged unless they have a separate meaning on their own (like barrier <https://wiki.openstreetmap.org/wiki/Key:barrier>=retaining_wall <https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dretaining_wall>)"* (*BOLD TEXT* is my addition) This is exactly what I've been saying *. Member ways should be untagged unless they have a separate meaning on their own. * There you have it. It's a logical system of tagging and makes perfect sense both from an initial standpoint and for ease of maintenance later on. On Sat, Nov 3, 2018 at 5:34 PM Mateusz Konieczny wrote: > 3. Nov 2018 11:30 by davefoxfa...@btinternet.com: > > Duplication of data leads to confusion, wasted time & errors. > Please refrain from mapping in this way. > > > Please refrain from demanding that other stop mapping in way that is > commonly accepted. > > > Suggesting, promoting and explaining alternatives is fine, but claiming > that one way is sole > > acceptable while it is untrue is irritating. > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag named group of named water areas?
Of course. The Trans Alaska Pipeline is as good an example as any. It is a man_made oil pipeline that stretches 1300 km across the entire state of Alaska. The relation contains 280 members. The reason there are so many members is because the pipeline way has been split into many individual pieces, separate ways, that have certain differing characteristics, e.g. where it runs underground or crosses a river on a bridge. The tagging for any specific way deals with those differing characteristics. A section might run for several miles underground and then emerge. At that point the pipeline way must be split into a section with location=underground and the emergent section with location=overground. Now it comes to a river that it crosses on a bridge. The pipeline way is split again into a section that has the tags bridge=yes and layer=1. You do the same thing to a highway where the number of lanes changes, or maxspeed. Each change requires you to split the way. Now say you've been tagging each piece with all the tags required rather than the relation. You decide to add a Wikipedia tag to the pipeline. Using your method, you must edit every piece of the pipeline, all 280 sections of it, and add the Wikipedia tag. Tagging the relation with the Wikipedia entry, however, requires only one edit. To make matters worse, let's just say you misspelled the Wikipedia tag value. You meant to write "wikipedia=en:Trans-Alaska Pipeline System" but forgot to include the "en:" prefix. Back you go to your editor, editing all 280 pieces again. That's why I say tagging it this way is a maintenance nightmare. I would only use tags on a particular way when its characteristics demand it. Tags that apply to the entire pipeline belong in the relation. Tags like the Wikipedia tag, substance=oil, man_made=pipeline, operator, alt_name, etc., belong on the relation. However, tags like bridge and location, tags that apply to individual sections or ways, get applied to the ways and not the relation because they don't apply to the entire pipeline. On Sat, Nov 3, 2018 at 4:25 AM Mateusz Konieczny wrote: > 2. Nov 2018 01:04 by daveswarth...@gmail.com: > > The only tags that should appear on the ways themselves are attributes of > those ways, for example, location=overground or location=underground, and > tags for bridge and layer. Everything else, Wikidata, substance=oil, > man_made=pipeline, etc, should appear only on the relation. > > > I am not convinced that it is a good idea. > > > > If those tags appear on each way in addition to the relation, maintaining > any consistency in the tagging on this beast would be almost impossible. > > > Can you give examples of task that you claim to be almost impossible? > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag named group of named water areas?
Allan, I'm not about to remove any tags from the highways in Turkmenistan. This isn't about an edit war. It's about trying to do things in the most efficient way possible. Using your highway as an example, let's say it has dozens of segments, each tagged with ref and other items as you indicated. Now let's say the ref changes. Someone must go in and retag every piece of your highway system; every bridge, every tunnel and every section that has a different number of lanes, a different maxspeed, or a different "local" name. It's a tricky operation at best and easily avoided. Because if that ref tag appears only in the relation, changing it involves only one edit, that of the ref tag inside the relation. The tags you're using on individual pieces of the highway are fine. I'm not saying you shouldn't continue to do what you have been doing. I'm only asking what is the correct way. Also, whether the relation renders the way one desires or not shouldn't be part of this discussion. We all want the stuff we map to be visible on the map products we use. But if certain relations aren't showing up on maps it's the map products that need to be fixed rather than our tagging methodology. Respectfully, Dave On Fri, Nov 2, 2018 at 8:44 AM Allan Mustard wrote: > I don't see a problem with duplicating a tag in both the relation and > sections of the object. In my case I have been mapping the national > highway network of Turkmenistan the last few months. I have created > relations so that all segments belong to one or more highways (P-1 from > Ashgabat to Koneurgench, for example). However, most map renderers will > not indicate that, plus the road is known to locals in most areas by that > name, so I have also added it to the name=* and ref=* tags. Too much > data? I don't think so. Each tag serves a slightly different purpose, and > the relation serves a wholly different purpose and is not visible in most > map products. > > Please don't go to the Turkmenistan map and delete all my hand-entered > tags on the highways! > > Allan Mustard > > On 11/2/2018 5:04 AM, Dave Swarthout wrote: > > Putting aside the discussion about type for a moment, this topic relates > to a discussion I'm having with a user about tags and multipolygons, > specifically where the tags go, so I believe it fits into this discussion. > I removed the tags from the ways for a section of the Trans Alaska Pipeline > (TAP) because those same tags were on the relation itself. The user asked > in a changeset comment why I had done that. I replied that IMO, any tags > that applied to the pipeline as a whole belong on the relation and need > not, indeed should not, be repeated on each way. The TAP is 1300 km long, > has countless bridges and sections where it is underground and then > overground. The only tags that should appear on the ways themselves are > attributes of those ways, for example, location=overground or > location=underground, and tags for bridge and layer. Everything else, > Wikidata, substance=oil, man_made=pipeline, etc, should appear only on the > relation. The folks who added the pipeline mostly via Tiger imports many > years ago tagged both. When I would occasionally add or replace a section, > I was always careful to copy all the tags from a neighboring section to the > new section. Now, I think that is incorrect. > > If those tags appear on each way in addition to the relation, maintaining > any consistency in the tagging on this beast would be almost impossible. I > have done quite a bit of re-aligning of the TAP over the years as our > available imagery improves but have always been tentative about removing > those redundant tags thinking I would get around to it someday. In fact, it > seems apparent that this is one major reason relations were invented, > especially for objects like routes — to ensure tagging consistency and > connectedness between the many individual member ways that comprise the > whole. > > So, what is the correct and accepted way to tag something like the TAP? > > Dave > > On Sat, Oct 13, 2018 at 7:17 AM Kevin Kenny > wrote: > >> why not a multipolygon? I agree that you don’t need additional tags for a >>> group relation, just type=group, a name and the members, but for a site you >>> would need something that describes the site, a tag for a group of water >>> areas, so as long as all the members are areas (or parts), a multipolygon >>> would be better. >>> >> >> When the lakes themselves are complex multipolygons with many islands, >> repeating that data for the group is likely to be a maintenance nightmare. >> (I know this from curating boundary=protected_area relations that include >> partial shorelines on such lakes. It's especially fun when the bounda
Re: [Tagging] How to tag named group of named water areas?
Putting aside the discussion about type for a moment, this topic relates to a discussion I'm having with a user about tags and multipolygons, specifically where the tags go, so I believe it fits into this discussion. I removed the tags from the ways for a section of the Trans Alaska Pipeline (TAP) because those same tags were on the relation itself. The user asked in a changeset comment why I had done that. I replied that IMO, any tags that applied to the pipeline as a whole belong on the relation and need not, indeed should not, be repeated on each way. The TAP is 1300 km long, has countless bridges and sections where it is underground and then overground. The only tags that should appear on the ways themselves are attributes of those ways, for example, location=overground or location=underground, and tags for bridge and layer. Everything else, Wikidata, substance=oil, man_made=pipeline, etc, should appear only on the relation. The folks who added the pipeline mostly via Tiger imports many years ago tagged both. When I would occasionally add or replace a section, I was always careful to copy all the tags from a neighboring section to the new section. Now, I think that is incorrect. If those tags appear on each way in addition to the relation, maintaining any consistency in the tagging on this beast would be almost impossible. I have done quite a bit of re-aligning of the TAP over the years as our available imagery improves but have always been tentative about removing those redundant tags thinking I would get around to it someday. In fact, it seems apparent that this is one major reason relations were invented, especially for objects like routes — to ensure tagging consistency and connectedness between the many individual member ways that comprise the whole. So, what is the correct and accepted way to tag something like the TAP? Dave On Sat, Oct 13, 2018 at 7:17 AM Kevin Kenny wrote: > why not a multipolygon? I agree that you don’t need additional tags for a >> group relation, just type=group, a name and the members, but for a site you >> would need something that describes the site, a tag for a group of water >> areas, so as long as all the members are areas (or parts), a multipolygon >> would be better. >> > > When the lakes themselves are complex multipolygons with many islands, > repeating that data for the group is likely to be a maintenance nightmare. > (I know this from curating boundary=protected_area relations that include > partial shorelines on such lakes. It's especially fun when the boundary > splits islands.) > >> ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
