[Tagging] Feature Proposal - RFC - appointment
Proposal for opening_hours syntax element "appointment", similar to "open" and "off": https://wiki.openstreetmap.org/wiki/Proposed_features/Opening_hours:_standard_appointment_syntax Kind regards Ruben ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reusable packaging
On Fri, 13 Sep 2019 13:07:13 +0100, Paul Allen wrote: > I'm not sure if there's a generally-accepted > term for this > in British English yet. I've seen "zero waste" (misleading, because it's > not zero) and > "unpackaged" (also misleading as it is in a package, just not a package > that you can > take away) as well as "bring your own container." There are also "plastic > free" > shops, but that doesn't necessarily mean the same thing, although there is > quite > a lot of overlap. There has been discussion about this on the forum: https://forum.openstreetmap.org/viewtopic.php?id=66456 I had drafted a (in retrospect not perfect) proposal as well: https://wiki.openstreetmap.org/wiki/Proposed_features/Low_waste_and_zero_waste ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - appointment
On Tue, 10 Sep 2019 18:59:29 +1000, Warin <61sundow...@gmail.com> wrote: > 'opening_hours="By appointment, phone "' (the ### is the phone number > that I don't recall of the top of my head. > > I think this is more versatile than yet another value as it allows an > individual response in the local language. I see "local language" as a big drawback in the following reasons: - Data consumers might want to handle appointments differently. For example a POI browser that shows "now open" could use a different colour for "now open on appointment". - Tourists using OsmAnd don't always understand the local language. - In bi-lingual areas like the capital of Belgium, using local language would mean using both Dutch *and* French. Do you have a more concrete example of what versatility you would be after? Something like Mo-Fr 09:00-18:00 "on appointment for non-members"? Also note that the appointment keyword would allow additional comments. This works when specific instructions are needed like Mo-Fr 09:00-18:00 appointment "don't call, use the website". ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - Donation
Hello everyone I created a proposal for all kinds of donation facilities (like donation of clothes or blood): https://wiki.openstreetmap.org/wiki/Proposed_features/Donation Kind regards Ruben aka M!dgard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] complete tagging of all 'right of way'-cases
> 10 May 2018 16:36:46 by Martin Koppenhoefer : >> 10. May 2018 14:57 by RubenKelevra : >> >> # Currently approved tagging >> >> stop signs: >> >> Stop signs are currently tagged at the position of the stop line, >> as a node on the way with the direction of traffic flow - which >> needs to be stopped. >> >> yield signs: >> >> Yield signs are tagged the same way stop signs are tagged. > this tagging only works in the case of one way streets or separate > carriageways, otherwise it is not clear to which direction the tags > apply (you have to look for the closest intersection and guess, which > will often work but isn’t a real solution) Well, both tags are combined with a direction tag: direction=forward/backward Best regards, Ruben ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] complete tagging of all 'right of way'-cases
> 10 May 2018 16:58:23 +0200 Mateusz Konieczny > : >> 10. May 2018 14:57 by ru...@vfn-nrw.de <mailto:ru...@vfn-nrw.de>: >> # currently missing: right-before-left/left-before-right >> >> Since there is no tag for this, I guess it's reasonable to define >> one the same way as for 4-way-stops. I think highway=give_way and >> give_way=all or default (analog to maxheight) makes the most sense >> (currently give_way=all is used 3 times worldwide). >> >> If right-before-left or left-before-right should be decided by the >> national boundary, not on any intersecting node. > give_way=no_priority? Yeah, this one sounds better. > 10 May 2018 16:53:30 by Mateusz Konieczny : >> 10. May 2018 14:57 by ru...@vfn-nrw.de: >> Hey guys, >> # currently missing: priority road by road design >> A lowered curb at a street on an intersection makes this road to >> yield, without the need for a sign (in Germany) >> I think we should tag this separately since there are no signs >> involved. I have currently no idea how to tag this. > Wiki already documents that highway=give_way is for > "Used to mark give way (also known as yield) signs or markings" > > I would consider it as a form of marking, close to painted signs like > at > > https://wiki.openstreetmap.org/wiki/File:Junction_of_Cleveland_Road_and_Ratcliffe_Close_-_geograph.org.uk_-_1518836.jpg > <https://wiki.openstreetmap.org/wiki/File:Junction_of_Cleveland_Road_and_Ratcliffe_Close_-_geograph.org.uk_-_1518836.jpg> Thanks for the hint, this sounds like we should add a subtag, like give_way:type=[curb, road_marking, sign, inferred] or give_way=[curb, road_marking, sign, inferred] (since this tag has zero usage currently this also works for stop=* or stop:type=*. The last value can be used when it's obvious, but no special markings can be found (already discovered two such spots in my surroundings today). Since I'm not a native English speaker, correct me when I misuse this word. :) > 10 May 2018 16:53:30 by Mateusz Konieczny : > PS You may wish to make shorter mails in future and try to tackle one > issue at once > > (maybe with link to essay describing all related concepts). > > It will avoid tl;dr problem. Well, thanks. I thought a not so cluttered way to deliver all necessary information would be better. It's actually hard to break down since all approaches currently focus on just one specific topic. I like to fix this with a step back and a look at the whole picture, to find an evenly acceptable solution for all cases. Best regards, Ruben ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] complete tagging of all 'right of way'-cases
> 10 May 2018 19:37:11 Martin Koppenhoefer : > > On 10. May 2018, at 19:12, Ruben Kelevra wrote: > > > > Well, both tags are combined with a direction tag: > > > > direction=forward/backward > > > which is intrinsically flawed, as it gets added to a node but nodes > don’t have a direction. Yep. It's a mess and really bad to parse and check for consistency. Also pretty hard to understand. I fixed many highway=stop nodes which are actually the intersection nodes, so even the primary_road was considered to stop there... which makes no sense. What do you think about the relation-approach designed by AMDmi3: https://wiki.openstreetmap.org/wiki/Relations/Proposed/Give_way Best regards, Ruben ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] complete tagging of all 'right of way'-cases
> 10 May 2018 13:54:09 -0700 Tod Fitch : > There are “four way”/“all way” stops in my area where traffic on the > primary road is required to stop. I map those by putting the > highway=stop on the junction node. For those where not all the ways > are required to stop, I put the highway=stop on the “limit line”. My > reading of the wiki a while back implied that was all that was > needed. More recently, based on mail list discussions, I have been > adding direction=forward/backward on those too. > > Not sure why a relation is needed for these as it is pretty simply to > tag and, I assume, for a data consumer to use the current tagging. I think we're fine with more than one solution, for a simple 4-way-stop a node in the intersecting-node and direction=all should be enough for data consumer. Analog to this, a tag on the intersecting node of two streets with a priority-to-the-right should be enough as well. I guess 'highway=give_way; give_way=right' or similar should be okay. If there's a left-hand-country using this law in the opposite direction an analog 'highway=give_way; give_way=left' would be added. But this neither allows many options to add nor to handle special cases. So we need more. Best regards, Ruben ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] complete tagging of all 'right of way'-cases FOLLOWUP
Hey guys, If the first one was TL;DR ... I start with working on this proposal to implement a give_way as a relation. This might be one of many to this topic and I'll follow up every different one when I start working on them. I thought some hours about this old proposal[1] and decided to update[2] it. It now includes the ability to tag the * used sign (directly at the intersection) * road markings, like a curb or a dotted or solid line * main operational function of this intersection, like a traffic light. The last one is necessary because we got intersection with stop and yield signs here, which are located at the traffic lights. So if the traffic lights are off (in the night or just non-operational) the signs located at the traffic lights are applied. When the traffic lights are shut of every night, we can add that information to the node at the via tag, to disable the traffic light tag in those time periods for the routers. Then the give_way- or stop-relations come into action. It now also includes lists of cases where it should be used and cases where it shouldn't. Explicitly changing the recommendation to NOT use it on roundabout & removing the example for it). It's also recommending the simple solutions for a priority-to-the-right (not yet written) and the all-way_stop. If the mapper wants to map more details, like the curbs, signs, hour_on/off or the class of vehicles where this applies, we have to go the relation way and create up to 4 relations to one intersection - I just don't see a simpler way with the same flexibility. [1] https://wiki.openstreetmap.org/wiki/Relations/Proposed/Give_way [2] https://bit.ly/2IrMh3g (just a shorted link to a diff) As always: Feel free to fix logic and language issues in the proposal - I'm not a native speaker, there might be many. I hope for more feedback on this from you, guys. Best regards Ruben ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] complete tagging of all 'right of way'-cases FOLLOWUP
Hey guys, I've took the proposed give_way relation and did the minor tweaks the original author, AMDmi3, probably had in mind to create a stop relation. Sure the == Rationale == I'm too tired now, will do this soon. https://wiki.openstreetmap.org/wiki/Relations/Proposed/stop As always: Feel free to fix logic and language issues in the proposal - I'm not a native speaker, there might be many. I hope for more feedback on this from you, guys. Best regards Ruben ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] complete tagging of all 'right of way'-cases
10 May 2018 23:57:00 Martin Koppenhoefer : > generally, a relation is capable of explicitly modelling the > situation, at the cost of complicated/time consuming actions required > from the mapper (and nowadays, with a lot of mapping on mobile phones > going on, average editor relation support is even worse). Personally, > I am mapping in a context with a lot of oneway streets, so it often > is not an issue to just use a node close to the intersection, I > believe if you can, you should avoid relations because it makes the > map more complex for others to understand and modify (maybe with the > exception of well supported multipolygon relations). I understand you're concerned, but we already have very complex solutions for bus routes, turn restrictions and hiking routes. A typical street inside a city usually contains easily dozend relations. In the early days, this was an issue with certain editors, but this time is long gone. Sure, newbies tend to break stuff, but we have tools to find those broken relations and fix them. I don't see an issue with this kind of complexity. I've added some of those relations to test out different usecases and it's not harder or take longer than to add a node and move it around. I might be trained working with relations, but I don't think it's a huge disadvantage in this case. > The particular proposal seems thought through, but might eventually be > overengineered. Yeah, might look like first, but our data users always envolve and we had a long time no useable data on this topic. Noone is using those highway=stop/give_way. The reason is simple, they are often broken, not easy to parse and this might lead to unexpected results. I think this might change in the future - like it did with the turn_restrictions. In the future, we're able to even tag those cases :P https://en.wikipedia.org/wiki/Traffic#/media/File:Milit%C3%A4rwegweiser_Flugplatz_Mollis.JPG > In the simplest representation you would only need a > via node (at the stop line) and a from way (ending at the stop line) > and be done. No, you misunderstood the proposal. It's basically exactly the same as a turn restriction. You don't split the way between the stop line and the intersection, but just add the intersecting node with a via-role. If you have two ways crossing: X and Y with intersecting node A. You select A as via-node and X as from-way and Y as to-way. If you want to map the exact location of the sign, you can add an additionally node at the place and add this node as traffic_sign and map it with traffic_sign=DE:205. Now a renderer might draw the sign exactly at the location you've mapped. If you want just the old behavior the proposal explains it, too: role location_hint - "a hint to a renderer as to where might be a good place to position a symbol indicating the give way. [...] Note that this member has the same meaning as an obsoleted highway=give_way node." > I am not sure how several via ways should work together with several > from and to ways, and I guess even if it works, it will be > complicated to evaluate (for other mappers) and several very simple > relations (only from way and via node) would probably be much easier > to understand (at the cost of having to split the ways at the > stop/via). One relation is just for one stop or give_way sign. So if there are all ways exactly the same, a simpler solution without any relation is much better. I want to create an additional proposal for this. This would look like this: https://www.openstreetmap.org/node/102697766#map=19/51.13736/7.20594 A bit more complex case, which was previously not tagable at all can be found a bit south: https://www.openstreetmap.org/node/102694679 (intersecting node) The street has just a curb, no signs to the right and the left. Since we were just able to tag signs, previously no information about this was available at all in our database. PS: I hope my explanations were understandable, I'm a bit tired and that's the last mail today. If not, just let me know. Best regards Ruben ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - Voting - Donation
Hello A year ago I started a proposal for donation facilities, covering everything from blood donation centres to clothes containers. Since then I've limited it to blood and other "body products". I'd like to start the voting process now: https://wiki.openstreetmap.org/wiki/Proposed_features/Donation Kind regards Ruben, aka M!dgard 2014-06-06 23:55 GMT+02:00 Ruben : > Hello everyone > > I created a proposal for all kinds of donation facilities (like donation > of clothes or blood): > https://wiki.openstreetmap.org/wiki/Proposed_features/Donation > > Kind regards > > Ruben aka M!dgard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Donation
Thanks for the feedback, everyone. Replied inline below. 2015-06-10 1:58 GMT+02:00 Andreas Goss : > Honestly I don't think it's such a good idea to start voting 1 year later > when there wasn't an ongoing discussion. > > > I'm not sure about amenity=donation when some things are very different. > I also feel like bood_bank, sperm_bank (do we want to tag those?) and I'm not a native English speaker but according to Wikipedia[1] "blood bank" means a place where blood is stored, not collected. Maybe there's a difference between BE and AE? > amenity=social facility would cover most of it and there are other like > shop=charity etc. So we already have a lot of POIs where you could just add > donation:*=yes. > With that in mind limiting the prosoal to those few tags also makes little > sense, might as well use healthcare=donations then. > > donation:facility=mobile makes no sense as we don't tag this. At best this > could be some HOT tag. In Belgium there are places where a mobile blood collection team visits regularly[2]. I've mapped an example[3]. [1] https://en.wikipedia.org/wiki/Blood_bank [2] http://www.rodekruis.be/wat-kan-jij-doen/geef-bloed/waar-bloed-geven/ [3] https://www.openstreetmap.org/node/3586748252 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Donation
Replied inline below. 2015-06-10 6:52 GMT+02:00 Holger Jeromin : > Warin <61sundow...@gmail.com> Wrote > in message: > >> Ok .. I'm wrong there.. you can donate just blood plasma. >> >> Not normal practice here for donations. A normal blood donation is >> whole blood. >> >> But maybe in other places they do plasma only? >> > > Plasma only is common in Germany, at least in Aachen. Here in Belgium too. The machine separates the plasma from the rest of the blood in real-time, and gives the latter back to you when its buffer is full. You don't have to wait as long after a plasma donation, because the impact on your body is lower. In Belgium it's two weeks after a plasma donation, and a few months after a whole blood donation. > We have blood donation fully integrated in Healthcare 2.0 as far > as I remember. > I do not see the need for a separate tag proposal. The closest I could find is healthcare=blood_bank, in the proposal page for Healthcare 1.0, with a link to "blood bank" on Wikipedia[1] (where it says "A blood bank is a cache or bank of blood or blood components, gathered as a result of blood donation or collection, stored and preserved for later use in blood transfusion."). The word "blood" is never used in Healthcare 2.0 as far as I can see. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Donation
Maybe healthcare=blood_donation would be better? Less "generic-but-not-actually-generic", and a clear description of what it is. I'm thinking about aborting the proposal and re-writing it with healthcare=blood_donation, and abandoning the facility=mobile/dedicated/hospital tag, but I would like to hear your opinions. 2015-06-10 23:42 GMT+02:00 Ruben Maes : > Replied inline below. > > 2015-06-10 6:52 GMT+02:00 Holger Jeromin : >> Warin <61sundow...@gmail.com> Wrote >> in message: >> >>> Ok .. I'm wrong there.. you can donate just blood plasma. >>> >>> Not normal practice here for donations. A normal blood donation is >>> whole blood. >>> >>> But maybe in other places they do plasma only? >>> >> >> Plasma only is common in Germany, at least in Aachen. > > Here in Belgium too. > The machine separates the plasma from the rest of the blood in > real-time, and gives the latter back to you when its buffer is full. > You don't have to wait as long after a plasma donation, because the > impact on your body is lower. In Belgium it's two weeks after a plasma > donation, and a few months after a whole blood donation. > >> We have blood donation fully integrated in Healthcare 2.0 as far >> as I remember. >> I do not see the need for a separate tag proposal. > > The closest I could find is healthcare=blood_bank, in the proposal > page for Healthcare 1.0, with a link to "blood bank" on Wikipedia[1] > (where it says "A blood bank is a cache or bank of blood or blood > components, gathered as a result of blood donation or collection, > stored and preserved for later use in blood transfusion."). > The word "blood" is never used in Healthcare 2.0 as far as I can see. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Donation
2015-06-13 1:21 GMT+02:00 Holger Jeromin : > Ruben Maes > Wrote in message: >> Replied inline below. >> >> 2015-06-10 6:52 GMT+02:00 Holger Jeromin : >>> Warin <61sundow...@gmail.com> Wrote >>> in message: > >>> We have blood donation fully integrated in Healthcare 2.0 as far >>> as I remember. >>> I do not see the need for a separate tag proposal. >> >> The closest I could find is healthcare=blood_bank, in the proposal >> page for Healthcare 1.0, with a link to "blood bank" on Wikipedia[1] >> (where it says "A blood bank is a cache or bank of blood or blood >> components, gathered as a result of blood donation or collection, >> stored and preserved for later use in blood transfusion."). >> The word "blood" is never used in Healthcare 2.0 as far as I can see. >> > > > Sorry, it is on the speciality sub page > health_specialty:transfusion_medicine > > > -- > Holger I'm not sure about which health_facility:type I should use. health_facility:type=...? + health_specialty:transfusion_medicine=main I would say health_specialty:transfusion_medicine is meant to say that this is the office of a doctor in the transfusion medicine. Could you please provide an example of a tag combination that would make it that clear it is a blood donation centre? IMO the healthcare 2.0 scheme is too bulky, or perhaps just not explained well. Kind regards Ruben ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Reception Desk.
Hi I'm a bit late here (just recently started really reading the tagging list), but could this also be used for "reception webcams"? In my city's hospital, the reception desk has been replaced with a tv screen and a camera. The receptionist is at the other campus of hospital, in another town, 15 km from where you are standing. All the best Ruben 2015-06-16 2:52 GMT+02:00 Warin <61sundow...@gmail.com>: > I think I'll be closing this shortly. Possibly tomorrow. > > There are some 10 votes, one against, the majority approving. > > There were close to 40 votes last time... where has the passion gone? > > On 2/06/2015 8:47 AM, Warin wrote: > > Hi, > > Voting for the mark 2 version of Reception Desk is now open. > > Link > https://wiki.openstreetmap.org/wiki/Proposed_Features/amenity%3Dreception_desk > > > A Reception Desk provides a place where people (visitors, patients, or > clients) arrive to be greeted, any information recorded, the relevant person > is contacted and the visitor/s, patient/s, or client/s sent on to the > relevant person/place. > > > It is particularly useful to know the location of the reception desk when it > is located away from the typical place (near a front entry) or where there > is only one amongst a number of large buildings. First seen as a suggested > extended tag for camp sites, thought to have a wider application to offices, > hotels, hospitals and educational features. > > The amenity key is chosen so it can be used for both tourism and business > situations. > > > Thanks for your participation. > > > > ___ > 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] Feature Proposal - Voting - Reception Desk.
2015-06-16 12:49 GMT+02:00 Warin <61sundow...@gmail.com>: > On 16/06/2015 8:46 PM, Warin wrote: >> >> On 16/06/2015 8:02 PM, Ruben Maes wrote: >>> >>> Hi >>> >>> I'm a bit late here (just recently started really reading the tagging >>> list), but could this also be used for "reception webcams"? In my >>> city's hospital, the reception desk has been replaced with a tv screen >>> and a camera. The receptionist is at the other campus of hospital, in >>> another town, 15 km from where you are standing. >> >> > Question.. Is there still a 'desk' there? For filling out forms, even jst > picking up a map/brochure? I don't remember that well, but I think so. > > >> Wow. Is the doctor 15km away too? :-) No :p But you're laughing at it, don't they do remote surgeries these days? https://en.wikipedia.org/wiki/Remote_surgery >> The tag applies .. the place a visitor goes to for info etc >> >> So yes... it is not about the 'desk' that is used to separate it from >> weeding reception, GPS reception, etc. >> I'll have to make that clear in the tag! The name is the best I could come >> up with. Not too late to change it if someone has a better name? >> >>> >>> All the best >>> Ruben >> >> >> Note on the distance to the Doctor .. here in Australia 'we' have the >> Royal Flying Doctor Service (RFDS) .. >> the Doctor can be 1,000 km away, not far in a fast plane. >> ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Reception Desk.
I think this could adequately be handled with a subtag, such as reception_desk=manned/webcam/artificial_intelligence/... 2015-06-16 16:42 GMT+02:00 John Eldredge : > At one hospital here in Nashville, TN, they cut back on the number of > reception desks. The two primary entrances have desks with someone seated at > them. Three other entrances have an unstaffed desk, with a webcam and a > telephone. > > -- > John F. Eldredge -- j...@jfeldredge.com > "Darkness cannot drive out darkness; only light can do that. Hate cannot > drive out hate; only love can do that." -- Martin Luther King, Jr. > > > > > On June 16, 2015 5:48:03 AM Warin <61sundow...@gmail.com> wrote: > >> On 16/06/2015 8:02 PM, Ruben Maes wrote: >> > Hi >> > >> > I'm a bit late here (just recently started really reading the tagging >> > list), but could this also be used for "reception webcams"? In my >> > city's hospital, the reception desk has been replaced with a tv screen >> > and a camera. The receptionist is at the other campus of hospital, in >> > another town, 15 km from where you are standing. >> >> Wow. Is the doctor 15km away too? :-) >> >> The tag applies .. the place a visitor goes to for info etc >> >> So yes... it is not about the 'desk' that is used to separate it from >> weeding reception, GPS reception, etc. >> I'll have to make that clear in the tag! The name is the best I could come >> up with. Not too late to change it if someone has a better name? >> >> > >> > All the best >> > Ruben >> ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - Blood donation 2
After the proposal Donation was rejected, I tried to address the issues that were raised in a new proposal using healthcare=blood_donation: https://wiki.openstreetmap.org/wiki/Proposed_features/Blood_donation_2 You are of course welcome to point out any flaws. You are also welcome to improve the language if you like: make phrases more fluent, fix mistakes, etc. Kind regards Ruben ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Blood donation 2
2015-06-21 1:14 GMT+02:00 Warin <61sundow...@gmail.com>: > On 21/06/2015 3:03 AM, André Pirard wrote: > > On 2015-06-20 14:46, Ruben Maes wrote : > > After the proposal Donation was rejected, I tried to address the > issues that were raised in a new proposal using > healthcare=blood_donation: > > https://wiki.openstreetmap.org/wiki/Proposed_features/Blood_donation_2 > > You are of course welcome to point out any flaws. > You are also welcome to improve the language if you like: make phrases > more fluent, fix mistakes, etc. > > > Looks good at first read. Thanks. :) > > Thanks for taking care of this life-saving service! No problem, I'm a plasma donor myself! [More below ...] > > Some contributors will recall that facilities, amenities, healthcare > etc. are not map objects but attributes of them, usually a building > of which the tags apply such as address. > > For example, blood donation may periodically take place in a school, > giving (for example in one of the possible LST formats): > > building=school > > addr:street=* > > phone=*(that of the school (main tag)) > > ... > > building:blood_donation=yes > > blood_donation:phone=* > > If periodic then the times when blood donation is present would also be > needed! > > blood_donation:schedule= times, same format as opening-times tag? > That would be more important than a phone number (which might only be manned > during the opening hours/days). > > ... > > The tricky case is when blood donation happens in mobile vehicles. > > That recalls us mapping clouds and the horse in the meadow. > > There is no suggestion in the proposal to tag either mobile or periodic > facilities. > > So the proposal should be judged on the permanent facilities ONLY. > > Extending it to cover other things ? > > IMO I would not. > > A mobile service could be seen as periodic ... > A periodic service may not have a fixed period/schedule ... > I think the fixed facility can be mapped and verified easily. > Mobile and/or scheduled services are much more difficult to map and verify. > In the original proposal I included a tag for mobile collections but after reading the reactions on this list I realised it may be too much of a hassle and not worth it. I also thought about adding a url where you could check donation times instead of tagging those. Unfortunately the website of my country's division of the Red Cross (which operates the most important fixed and mobile donation centres) has no separate pages for them and their "donation place search engine" does not support direct linking to results. As for donation vehicles ... I wouldn't even think to map them. They can just park anywhere, whereas with the normal mobile collections there are fixed spots they always visit. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Blood donation 2
2015-06-22 23:20 GMT+02:00 Holger Jeromin : > Ruben Maes > Wrote in message: >> After the proposal Donation was rejected, I tried to address the >> issues that were raised in a new proposal using >> healthcare=blood_donation: >> >> https://wiki.openstreetmap.org/wiki/Proposed_features/Blood_donation_2 >> >> You are of course welcome to point out any flaws. > > In Healthcare 2.0 there is a tag defined (quite hidden), but I was > the only person who used it :-) > > In Aachen you can decide if you want money or a voucher from some > local companies ;-) > Some voucher have a bonus in the value. 25 euro vs 30 Euro voucher > or 25 euro cinema + 5 Euro popcorn / drinks A bit complicated ... My first thought would be changing the proposal to "donation:compensation=yes/no" and if yes, use subtags "donation:compensation:payment/vouchers/...=yes". So e.g.: – donation:compensation=no – donation:compensation=yes + donation:compensation:vouchers=yes (and let that imply that there's no payment) – donation:compensation=yes + donation:compensation:payment=yes + donation:compensation:vouchers=yes Looking for opinions here. With the vouchers you receive around here, you can only get small gifts in the donation centre itself, e.g. comics, (cheap) computer mice, bibs... With more vouchers you can also buy tickets for certain amusement parks. Would it be okay to have these vouchers and local company vouchers in the same tag? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] healthcare: attribute or stand alone tag? (was Re: Feature Proposal - RFC - Blood donation 2)
Op maandag 29 juni 2015 heeft André Pirard het volgende geschreven: > On 2015-06-29 18:55, Holger Jeromin wrote : >> André Pirard wrote on 29.06.2015 17:08: >>> Ruben Maes Wrote in message: >>>> After the proposal Donation was rejected, I tried to address the >>>> issues that were raised in a new proposal using >>>> healthcare=blood_donation: >>>> https://wiki.openstreetmap.org/wiki/Proposed_features/Blood_donation_2 >>>> You are of course welcome to point out any flaws. >>> Like I said, could you please in your proposal *stress* that healthcare >>> is not an object but an attribute of an object. >>> There is no such thing as "a healthcare" on a map but a building can be >>> used for healthcare. >>> Then, healthcare is an attribute of that building. >>> Out of curiosity, I've had a look at Key:healthcare >>> <https://wiki.openstreetmap.org/wiki/Key:healthcare> and it's exactly >>> what it says: >>>> ... add *healthcare*=* to to an area that has building >> Is this (5 years later) really still true? I am quite happy with my >> (indoor tagging) node: >> >> http://www.openstreetmap.org/node/1227761407#map=19/50.77699/6.04469 > What is "this"? > My remark concerns mainly areas (buildings). > But it's also interesting to know what a node represents (what > healthcare is an attribute of). >> Is a restaurant or hotel also a attribute to an object? > Of course it is. > They are the attributes that make a building (usually) suitable for > catering and accommodation. > >>> You should give an example of for example a school where blood_donation >>> takes place: >>> >>> building=school >>> or >>> building=yes >>> school=yes >> Eeks, not a good example tag :) > If you think so, you should say why and what you propose. > Not just the usual "no". > I think that such a page should teach the reader how to tag healthcare > taking place in a school. I have yet to see a permanent blood donation centre at a school, but I would just place a node with the healthcare tags in the school area and call it a day. Adding everything on the school boundary seems very odd to me, I have never seen that done. For renderers, I think it must be a nightmare. I know we're not supposed to tag for the renderer but any data consumer would have trouble interpreting dual-tagged objects. So to me, healthcare=blood_donation is pretty stand-alone (just like shop=*) and not an attribute of a school, a shop or even a hospital for that matter. I'd use it on a node without any other tags, but on a way of course with building=yes or whatever tags are relevant. (Also see the examples on the proposal page – do you agree with them or would you tag them differently?) I could add a piece about making sure to use a building tag to the page, but IMO then we'd have to do that on the wiki pages for all shops, most amenities, etc... Actually that might not be a bad idea? We could write a template and include it on those pages. I've seen people using JOSM not including building tags quite a few times. -- ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - Voting - Blood donation 2
Voting is now open on the modified proposal: https://wiki.openstreetmap.org/wiki/Proposed_features/Blood_donation_2 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Multiple values with semicolons (was: Voting - Blood donation 2)
Fkv voted no on Blood donation 2 because he believes the
donation:compensation:* keys will cause inconsistencies, e.g.
donation:compensation=no together with
donation:compensation:payment=yes. I can see his point though I don't
think it would happen often.
He proposes to use a semicolon-separated list, e.g.
donation:compensation=payment;vouchers.
We both know this is controversial, but why in fact?[1] It is supposed
to be hard to interpret for data consumers, but can't they just as
easily make a list with booleans of all the values that are present in
the tag?
1: donation:compensation=yesdonation:compensation:payment=yes
donation:compensation:vouchers=yes
2: donation:compensation=payment;vouchers
-> "compensation": true, { "payment": true, "vouchers": true }
(possible result in the memory of a parser)
1: donation:compensation=yesdonation:compensation:vouchers=yes
2: donation:compensation=vouchers
-> "compensation": true, { "payment": false, "vouchers": true }
1+2: donation:compensation=no
-> "compensation": false, { "payment": false, "vouchers": false }
Is there perhaps a significant performance drawback to having to parse
semicolon lists or what am I missing?
[1] wiki.osm.org/wiki/Semi-colon_value_separator explains you should
use the namespaced approach, but not why
2015-07-12 20:12 GMT+02:00 Ruben Maes :
> Voting is now open on the modified proposal:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Blood_donation_2
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
[Tagging] landuse=military
Op vrijdag 24 juli 2015 heeft Andre Engels het volgende geschreven: > "xxx=designated" means that a road has been specifically designated > for vehicle type xxx. "access=designated" would mean that it was > _specifically_ designated for _everything_. A contradictio in > terminis. This is also how I understand it. Having it on something other than a road does not make access=designated valid. access:GROUP_OF_PEOPLE=designated would make more sense but it's not optimal. -- ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Blood donation 2
Voting on http://wiki.osm.org/wiki/Proposed_features/Blood_donation_2 is due to close tomorrow. So far we've got 9 votes for and 1 against. If you'd like to cast your vote and haven't already, please do so ASAP. 2015-07-12 20:12 GMT+02:00 Ruben Maes : > Voting is now open on the modified proposal: > https://wiki.openstreetmap.org/wiki/Proposed_features/Blood_donation_2 2015-07-12 20:12 GMT+02:00 Ruben Maes : > Voting is now open on the modified proposal: > https://wiki.openstreetmap.org/wiki/Proposed_features/Blood_donation_2 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] access=designated wiki
2015-07-25 15:24 GMT+02:00 Andy Townsend : > On 25/07/2015 13:43, Hubert wrote: > It's also perhaps worth mentioning that the 18th Feb > change (which you - and I - preferred the previous version to) was made by a > wiki editor who's since been blocked (3). > > (3) http://wiki.openstreetmap.org/wiki/Special:Contributions/Xxzme Xxzme did nothing wrong there, he just removed an image that was there twice, a very sensible edit[1]. I mean, don't blame him for things he didn't do, it's bad enough as it stands :p Geow made all the mess. [1] https://wiki.openstreetmap.org/w/index.php?title=Tag:highway%3Dfootway&diff=1160471&oldid=1141274 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] access=designated wiki
2015-07-28 23:59 GMT+02:00 Hubert : > On 28. Juli 2015 22:32 Ruben Maes [mailto:ruben.mae...@gmail.com] wrote: >>2015-07-25 15:24 GMT+02:00 Andy Townsend : >>> It's also perhaps worth mentioning that the 18th Feb change (which you >>> - and I - preferred the previous version to) was made by a wiki editor >>> who's since been blocked (3). >>> >>> (3) http://wiki.openstreetmap.org/wiki/Special:Contributions/Xxzme > For clarification: I didn't write that. Sorry, my bad, got the quotes messed up. It was Andy Townsend who wrote it. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Blood donation 2
Voting is closed, blood donation has been accepted with 12 votes for and 2 votes against. Thanks to all who have voted! A tag page has been created and is already available in English, German and Dutch. Can I add this to the Map Features page under amenity > healthcare? 2015-07-25 13:00 GMT+02:00 Warin <61sundow...@gmail.com>: > Hi, > > Very disappointing that more have not voted. Coming up to August when some > go on holidays too, so holidays cannot be much of an excuse now? > > The proposal process wiki page says that voting may be extended beyond 2 > weeks ... give them an extra day or two? If some commence voting. > > http://wiki.openstreetmap.org/wiki/Proposal_process#Voting > > I'll be closing the 4 ones that I have current. > > > > On 25/07/2015 8:24 PM, Ruben Maes wrote: >> >> Voting on http://wiki.osm.org/wiki/Proposed_features/Blood_donation_2 >> is due to close tomorrow. >> So far we've got 9 votes for and 1 against. If you'd like to cast your >> vote and haven't already, please do so ASAP. >> >> 2015-07-12 20:12 GMT+02:00 Ruben Maes : >>> >>> Voting is now open on the modified proposal: >>> https://wiki.openstreetmap.org/wiki/Proposed_features/Blood_donation_2 >> >> >> 2015-07-12 20:12 GMT+02:00 Ruben Maes : >>> >>> Voting is now open on the modified proposal: >>> https://wiki.openstreetmap.org/wiki/Proposed_features/Blood_donation_2 >> >> ___ >> Tagging mailing list >> 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
Re: [Tagging] Telecoms Tagging
2015-07-23 0:12 GMT+02:00 François Lacombe : > Finally, and regarding mobile telecom networks, there is this chart which > try to illustrate components and relations to be made on a mobile station > https://wiki.openstreetmap.org/wiki/File:Radio_antennas_mapping_proposal.png Is there a reason for using the key "azimuth" instead of "direction"? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] highway=footway - Advanced definition: Distinction footway vs path
2015-08-06 11:24 GMT+02:00 John Willis : > So far in the replies, Ive read a sidewalk isn't a footway (its lanes on a road [no]) and a track in a wilderness park isn't a track (its a path [uhh, no]) > > Not being able to define sidewalks separately nor separate tracks from trails means all of the mapping is untrustworthy for proper routing nor proper rendering ***to represent the world as it exists*** You can use sidewalk=both/left/right. When micromapping, I might draw sidewalks that are really separated from the road separately. I always tag them with highway=footway + footway=sidewalk. When I connect them near crossings, I do those parts highway=footway + footway=crossing. --+-- highway=footway footway=sidewalk | ==x== highway=residential | highway=footway footway=crossing And the x gets highway=crossing of course. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fwd: Re: landcover=trees definition
I received your original message at 11:35. (UTC+02:00) On Monday 10 August 2015 11:56:27 Daniel Koć wrote: > Anybody other have problems with posts to the list getting lost? I > resend this one and hope this time it will get there: -- Ruben Maes The field "from" of an email is about as reliable as the address written on the back of an envelope. Use OpenPGP to verify that this message is sent by me. You can find my public key in the public directories, like pool.sks-keyservers.net. signature.asc Description: This is a digitally signed message part. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Some messages delivery problems [was: Fwd: Re: landcover=trees definition]
On Monday 10 August 2015 13:51:16 Daniel Koć wrote: > I didn't and I have also seen no trace of it in the archive for at least > 20 minutes. Now that I think of it, some messages of mine on other lists have also not been included in the archives but people responded to them. > In general I get them almost instantly and the archive shows them fast > too, but once or two my messages to this list (or maybe Talk?) got lost > completely. Maybe you can try and enable post acknowledgements at https://lists.openstreetmap.org/options/tagging/. -- Ruben Maes The field "from" of an email is about as reliable as the address written on the back of an envelope. Use OpenPGP to verify that this message is sent by me. You can find my public key in the public directories, like pool.sks-keyservers.net. signature.asc Description: This is a digitally signed message part. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Shop= values and a sub key for detail?
On Friday 14 August 2015 09:46:00 Warin wrote: > Hi, > > This follows from the shop=model discussion I raised a while ago. > > > Marczoutendijk diary > https://www.openstreetmap.org/user/marczoutendijk/diary/35584 > > demonstrates the issue that occurs with shop= ... > > I think one way to 'solve' this is to have a free text entry sub key for > shops... > > say a key of shop_products. > > In this way shop= values don't have to carry all the detail leading to > possibly millions of values. > Rather shop= values can be a collective value without the specific > detail, making them easier to distinguish by separate rendering icons. > If detail is required then the free text entry can be interrogated. > > Examples > shop=food > shop_products=cheese, bread, fruit, vegetables > > shop=scale_model > shop_products=kits, ready made, materials > > > shop=bicycle > shop_products=new, second hand, service > > Thoughts?? vending comes to mind, it is defined as being for vending machines. In any case, you should use semi-colons to separate multiple values. And semi-colon separated lists (here we go again) should be avoided (especially in new tagging schemes) in favour of namespaced tags. I vaguely remember an argument for things like vending:food:bread=yes. So, in combination with duck tagging, a shop selling mainly fruit and vegs would become something like shop=grocery vending:bread=yes vending:cheese=yes vending:fruit=yes vending:vegetables=yes And the scale model shop shop=model vending:scale_model_kits=yes service:scale_model:repair=yes (following the bicycle scheme) second_hand=yes (that is an approved tag: https://wiki.openstreetmap.org/wiki/Key:second_hand) For bicycle shops, there are already tags to describe this, see https://wiki.openstreetmap.org/wiki/Tag:shop%3Dbicycle. -- The field "from" of an email is about as reliable as the address written on the back of an envelope. Use OpenPGP to verify that this message is sent by me. You can find my public key in the public directories, like pool.sks-keyservers.net. signature.asc Description: This is a digitally signed message part. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Blood donation: mobile collections, 'attribute' status
On 14 August 2015, Papou wrote on the wiki[1]: > There were discussions related to this in other Tagging@ threads without > follow-up before the vote. > My disregarded remarks were: > * to introduce the tag precisely as: >healthcare=blood_donation is an attribute tag that indicates that the > object tag is a place where one can donate blood ... (building, room, tent, > parking place where a vehicle comes ...) As is shop=*. They are both not purely main objects, but also not purely attributes. You go to a building because the shop you want to visit is in it; you go to a building because you want to go to the blood collection. If the building is not primarily the shop, you tag the building with building=* and place a node inside with just the shop tags. Similarly for healthcare=blood_donation. This is a bit philosophical. > * also applying to healthcare=any (to be modified): the tag can be put on an > area object (typically building), but, preferably IMHO, unless the whole area > is devoted to donation, a node inside an area. In that case, having an > object tag such as a room in the node is required (you said you are happy > without) I did not previously understand your call for a 'room' tag. Indeed I am happy without a room tag if the building is not indoor mapped. If indoor mapping ever catches on, the outlines of rooms where blood donation takes place can be tagged with room=yes and healthcare=blood_donation. > * So that they were tagged uniformly, I suggested an example for the tagging > of several hundred Red Cross periodic donation spots, typically a node: >area: >building=school >contact:phone=* (and other tags related to the school) >... >node inside area: >room=yes >ref=12 >healthcare=blood_donation >contact:phone (and other tags related to blood donation such as: >contact:email=* >website=* >open_hours=Tu 17:00-19:30 "days on schedule (see website)" opening_hours=Tu 17:00-19:30 "days on schedule (see website)" seems far from perfect. Semantically, IMO, it is implied that the facility is open every Tuesday, with a comment for the user. Perhaps the opening_hours syntax could be amended. Another problem is that the mobile collections don't always occur on the same day of the week. For example, in Heist, Belgium, The upcoming mobile collections are We 19 August, Tu 25 August, Tu 10 November and We 18 November. I am not convinced that the mobile blood donations can be adequately mapped by this. They would at least need an additional tag. Also, they are points that are fixed in space, but not in time. OpenStreetMap normally requires both I think. However, I do like the idea of mapping them. Maybe we can ultimately get our Red Crosses to use OSM maps on their sites. > This last tag was discussed on the Tagging list especially for you to > indicate that the donations always take place on Tuesdays at the shown hours > and that the exact days have to be found at the given website URL. > > As a volunteer ex-cooperator of blood donation, I thank you for this. Thank you for elaborating on your point of view. I now better understand what you meant. [1] https://wiki.openstreetmap.org/wiki/Proposed_features/Blood_donation_2#papou-attribute-mobile -- The field "from" of an email is about as reliable as the address written on the back of an envelope. Use OpenPGP to verify that this message is sent by me. You can find my public key in the public directories, like pool.sks-keyservers.net. signature.asc Description: This is a digitally signed message part. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Blood donation: mobile collections, 'attribute' status
On Friday 14 August 2015 14:55:09 Martin Koppenhoefer wrote: > > Am 14.08.2015 um 13:50 schrieb Ruben Maes : > > > > If the building is not primarily the shop > > can you give an example where a building is the same as a shop (i.e. a > business)? https://www.openstreetmap.org/way/364872652, https://www.openstreetmap.org/way/272808143, https://www.openstreetmap.org/way/298383065 ... And here a healthcare=blood_donation on a building: https://www.openstreetmap.org/way/281211429 In Belgium it also seems to be popular to map the shop on the building itself if the rest of the building is just residential. > > , you tag the building with building=* and place a node inside with just > > the shop tags. > > this is the preliminary variant. More detailed alternatives comprise mapping > the business as an area (often done with a multipoligon relation to avoid > overlapping ways or wall thickness hyperbole details) Inside a building? Never done nor seen that before, it surely is not common practice around here. It's also not always easy to know the borders of the business inside. -- The field "from" of an email is about as reliable as the address written on the back of an envelope. Use OpenPGP to verify that this message is sent by me. You can find my public key in the public directories, like pool.sks-keyservers.net. signature.asc Description: This is a digitally signed message part. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Husainiya
Tuesday 18 August 2015 07:43:02, AbulAziz M.: > > Proposal page: https://wiki.openstreetmap.org/wiki/Proposed_features/husainiya Definition: A congregational place for Muslims (esp. Shia Muslims) where I sermon is given and the tragedy of Karbala is commemorated FYI, I've modified the Proposal Process on the wiki. It now also says to include a link to the proposal page. -- The field "from" of an email is about as reliable as the address written on the back of an envelope. Use OpenPGP to verify that this message is sent by me. You can find my public key in the public directories, like pool.sks-keyservers.net. signature.asc Description: This is a digitally signed message part. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Husainiya
Tuesday 18 August 2015 17:24:31, Ruben Maes: > Tuesday 18 August 2015 07:43:02, AbulAziz M.: > > > > > > Proposal page: https://wiki.openstreetmap.org/wiki/Proposed_features/husainiya > Definition: A congregational place for Muslims (esp. Shia Muslims) where I > sermon is given and the tragedy of Karbala is commemorated This should be expressed with subtags of place of worship: amenity=place_of_worship religion=muslim denomination=shia/... muharram=yes/no should be expressed with opening_hours instead, though it currently only supports the Gregorian calendar as far as I know. "weekly" should be expressed with service_times. throughout_the_year: I am not sure what you mean by that. -- The field "from" of an email is about as reliable as the address written on the back of an envelope. Use OpenPGP to verify that this message is sent by me. You can find my public key in the public directories, like pool.sks-keyservers.net. signature.asc Description: This is a digitally signed message part. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Opening hours specification (was: [talk] YoHours: opening_hours viewer and editor)
Friday 21 August 2015 11:48:49, panierav...@riseup.net: > > Hello, > > I recently released a new version of YoHours, a website which allows > everyone to create and view opening hours in the OSM syntax. It now > supports seasons-dependent hours (month, week, day, holiday selectors). > > It's available here: > http://github.pavie.info/yohours/ > > The code is available on GitHub: > https://github.com/PanierAvide/panieravide.github.io/tree/master/yohours > [1] > > If you have any suggestions, let me know :) > > Cordially, > > PanierAvide. > > > Links: > -- > [1] > https://github.com/PanierAvide/panieravide.github.io/tree/master/yohours I opened an issue[1] on this GitHub project, because it puts a colon after week, month and monthday selectors. PanierAvide replied that the specification allows an "optional separator for readability"[2]. Indeed, when you read the overly complicated and totally not mapper-focused specification, you can see [ ] [ ] [ ] [ ] Whose idea was this? It's already complicated enough that you don't have to add *optional* separators for supposed readability. IMO it's just fine without them. PS: I always follow the time domains proposal[3]. It's clear and it's compatible with the other specification AFAIK. [1] https://github.com/PanierAvide/panieravide.github.io/issues/1 [2] https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification#separator_for_readability [3] https://wiki.openstreetmap.org/wiki/Proposed_features/Time_domains -- The field "from" of an email is about as reliable as the address written on the back of an envelope. Use OpenPGP to verify that this message is sent by me. You can find my public key in the public directories, like pool.sks-keyservers.net. signature.asc Description: This is a digitally signed message part. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Opening hours specification
Friday 21 August 2015 13:29:37, Simon Poole: > BTW while it is still work in progress (now mainly because the android > UI isn't finished yet) > https://github.com/simonpoole/OpeningHoursParser is a JavaCC based > parser which attempts to implement the full spec, undoubtedly I've > probably missed one or two special cases, but it is fairly complete. > > It currently successfully parses 108'455 of 122'100 test strings (with > some relaxation of rules) of those that fail 10'569 seem to be valid > lexical errors and a large part of the remaining errors seem to have > other issues. The test strings were extracted from the OSM database > (nodes only). Cool. Maybe OsmAnd could implement it in the future. > As you say the specification itself is overly complicated (the > "optional" colon is not really a problem, except that it is not really > clear where it is allowed, there is some further similar fuzziness wrt > comments) and definitely shouldn't have more stuff added to it (with > perhaps the exceptions of adding further variable dates and similar things). There should be an easy to understand guide, that's meant for mappers and not only for developers. I've written a tutorial for the basics[1] but everything should be described clearly (not necessarily example-based). Because I know that by saying "there should be" on the mailing lists nothing will happen, I created a draft in my userspace[2]. I invite everyone that is interested in clearing this mess to join me. You can just change the page, no need to ask me for permission. There is too much information on the page, so I moved some content to subpages. [1] https://wiki.openstreetmap.org/wiki/Key:opening_hours/Tutorial [2] https://wiki.openstreetmap.org/wiki/User:M!dgard/Key:opening_hours -- The field "from" of an email is about as reliable as the address written on the back of an envelope. Use OpenPGP to verify that this message is sent by me. You can find my public key in the public directories, like pool.sks-keyservers.net. signature.asc Description: This is a digitally signed message part. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] landuse=religious & Monastic schools
Saturday 22 August 2015 21:13:09, John Willis: > > Sent from my iPhone I would like to politely express a feeling of disbelief as to why people leave that automatic signature turned on. Also, I would suggest you enable a setting that makes you confirm that you want to send an email. Sent from my Kubuntu laptop -- The field "from" of an email is about as reliable as the address written on the back of an envelope. Use OpenPGP to verify that this message is sent by me. You can find my public key in the public directories, like pool.sks-keyservers.net. signature.asc Description: This is a digitally signed message part. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Shop vs amenity
Tuesday 25 August 2015 11:30:33, Warin: > As the post office is called an office I suppose it should go as > office=post_office:-) > The more I think of a bank the more I think of it is an office. > Carpenter? If I want a repair done .. then it is a service? = office. If I > want a new chair then a product? = shop. ? Or craft=carpenter[1]. Craft is then for (quote from wiki) "place[s] producing or processing customized goods", to make things even more complicated. [1] https://wiki.openstreetmap.org/wiki/Tag:craft%3Dcarpenter -- The field "from" of an email is about as reliable as the address written on the back of an envelope. That's why this message is OpenPGP signed. signature.asc Description: This is a digitally signed message part. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] waterway=derelict_canal
Wednesday 26 August 2015 12:51:22, Dave F.: > Sub tags such as disused=yes have always been the way to describe > additional attributes of an entity. It's even the syntax used by XML: > you collect all 'waterway=canal' items then manipulate that selection > set. If programmers "don't notice" then, quite simply, they're not very > good at they're job. The point is that a disused shop is no longer a shop: A shop is a place you can go to to buy stuff or services. If the shop has closed, it's effectively not a shop any more and no longer of interest to most data users. -- The field "from" of an email is about as reliable as the address written on the back of an envelope. That's why this message is OpenPGP signed. signature.asc Description: This is a digitally signed message part. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] waterway=derelict_canal
Wednesday 26 August 2015 21:04:47, Andrew Errington: > Curiously, the disadvantages of "disused=yes" seem rather contrived, > and not really likely, whereas the disadvantages of "disused:*=*" seem > quite genuine. Not to mention that "disused=yes" is simpler, and very > obvious to a human reader. You're kidding, right? To me it's clear that disused:*=* is better for things that are no longer what they were, e.g. disused:shop=* If however you want to map a canal where the water is still present, I'm fine with waterway=canal, disused=yes since the feature is still a canal, even though it's no longer used. -- The field "from" of an email is about as reliable as the address written on the back of an envelope. That's why this message is OpenPGP signed. signature.asc Description: This is a digitally signed message part. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] highway=footway - Advanced definition: Distinction footway vs path
Friday 28 August 2015 18:28:44, ksg: > Some horse whisperer may translate that to English Done. I'm not a native English speaker nor a native German speaker so please do check the translation if you have the time. -- The field "from" of an email is about as reliable as the address written on the back of an envelope. That's why this message is OpenPGP signed. signature.asc Description: This is a digitally signed message part. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Access tags (general question, but mostly regarding bicycle)
Friday 28 August 2015 19:05:52, Mateusz Konieczny: > For example iD - is it clearly > indicating that it is about legal status? I am also regularly checking > situation in my region and fixing new problem. In English it's called "Access". How it's called in other languages depends on the translators. iD is translated at https://www.transifex.com/ideditor/id-editor/. I'm going to change the Dutch translation to (the equivalent of) "Legal access restrictions". -- The field "from" of an email is about as reliable as the address written on the back of an envelope. That's why this message is OpenPGP signed. signature.asc Description: This is a digitally signed message part. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] highway=footway - Advanced definition: Distinction footway vs path
Saturday 29 August 2015 12:46:04, Richard: > highway=footpath may cause less trouble. I think it would cause *more* trouble. This resembles highway=footway too much, especially for non-native English speakers. -- The field "from" of an email is about as reliable as the address written on the back of an envelope. That's why this message is OpenPGP signed. signature.asc Description: This is a digitally signed message part. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposed mechanical edit: surface=soil to surface=dirt (history (authors of changesets))
Wednesday 02 September 2015 13:51:09, André Pirard: > What policy, what purpose, that's unclear? > Is OSM.org using that API to display the history on the screen illegal? > Is Osmose using it to attribute errors to some user illegal? > Yep, I suppose that making oneself a complete list of OSM users is > inappropriate. No, the osm.org site doesn't use the API. Rather, it queries the database directly. I think it's not about "illegal" in the sense of prohibited out of privacy concerns or the like, but about the fact that we don't have unlimited capacity and that mappers mapping should not be hindered by people that want to query the API for unrelated uses. -- The field "from" of an email is about as reliable as the address written on the back of an envelope. That's why this message is OpenPGP signed. signature.asc Description: This is a digitally signed message part. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Handle with care (was: Accuracy of survey)
Friday 11 September 2015 19:16:09, André Pirard: > But JOSM says "The server responds with the return code 404 instead of 200. " > when trying to validate http://dev.openstreetmap.org/ as well as > http://api06.dev.openstreetmap.org/ > Thanks, but please give correct information. Hi André The exact URL you need to enter is: http://api06.dev.openstreetmap.org/api To edit the map you'll have to create another account at http://api06.dev.openstreetmap.org/. -- The field "from" of an email is about as reliable as the address written on the back of an envelope. That's why this message is OpenPGP signed. signature.asc Description: This is a digitally signed message part. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Semi-detached houses: undocumented iD preset
Hi all Yesterday iD got a new preset: building=semidetached_house. https://github.com/openstreetmap/iD/issues/2776 This tag is *not documented anywhere at all*. Additionally it seems to merely be the result of an import ([1]) (See my comments on the GitHub issue.) Bryan doesn't see any problems with undocumented tags. I do ([2]) so I want to have this tag either officially approved and documented or officially obsoleted by another tag. I think the tag in se is fine, though not really consistent with building=detached. Does anyone think a better value would be more appropriate? If it's ok, I'll created a proposal for it based on my understanding of the tag. Cheers Ruben [1] It introduced building:type=semidetached_house, building:type=dwelling_house, building:type=row_house and building:type=multi_storey. A lot but not all occurences seem to have been mechanically changed from building:type=* into building=*. [2] * It makes the data look wrong * It does not allow mappers to understand how it should be used * It doesn't give the devs of other editors the chance to implement it as well * Mappers of other editors are not encouraged to use it and may well never even hear about it * You can't know if you are mapping it correctly * Data users can't know about it, even though they may well be interested in supporting it etc... -- The field "from" of an email is about as reliable as the address written on the back of an envelope. That's why this message is OpenPGP signed. signature.asc Description: This is a digitally signed message part. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Semi-detached houses: undocumented iD preset
Thursday 17 September 2015 16:48:48, Martin Koppenhoefer: > > sent from a phone > > > Am 17.09.2015 um 16:29 schrieb Ruben Maes : > > > > building:type=semidetached_house, > > is ok for me. We should write a definition into the wiki, thank you for > preparing a proposal. > > > building:type=dwelling_house, > > is this a house where someone is living? I prefer the values detached house > and villa, maybe also hut/cabin? > > > building:type=row_house and > > I believe these are the same as terraced houses? > > > building:type=multi_storey. > > quite generic, we also have apartments, condominium, tower, office_tower, ... > basically you can see by building_levels tag how many storeys a building has. Yes, that was my point ;) None of those values are OK, but iD wants us to embrace semidetached_house? signature.asc Description: This is a digitally signed message part. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Semi-detached houses: undocumented iD preset
Friday 18 September 2015 09:47:12, Frederik Ramm:
> When someone adds copious "is_in" tags to things, or when they create
> relations like "all cycleways in Cambridge", we tell them: Don't bother
> doing that, we use a spatial database, and we can compute these things
> from the data.
>
> I'd say the same applies to houses. Whether something is one half of a
> double house, or semi-detached, or terraced, or free-standing - isn't
> that something that I can automatically determine by looking at the
> nearby mapped buildings?
>
> Or is the redundancy desirable so that we can then write new debugging
> tools ("house at end of row but not tagged as semi-detached", etc?)
I thought that at first about building=detached as well. If I remember
correctly, someone said that figuring it out is a database query that takes
long.
The original import tagging page [1] says semidetached_house is used for
Doppelhäuser which is not exactly the same as just two houses that share a
wall, right? For example: I wouldn't consider these houses[2] semi-detached
because they have a very different architecture and no shared roof, while I
would have to think twice about these ones[3]. Their architecture and colour is
the same, but they have a flat, not-really-shared roof IIRC.
According to Wiktionary, it is called a duplex in American English, in British,
Australian and Canadian English a semi and in all Englishes a semi-detached.
That would make the "house" part even unnecessary, but useful to understand the
meaning of the tag (unlike building=detached).
[1] https://wiki.openstreetmap.org/wiki/Rostock:Geb%C3%A4ude_und_Strukturen
[2] http://osm.org/go/0EhfysLT0?m=
[3] http://osm.org/go/0EhfynMd2?m=
signature.asc
Description: This is a digitally signed message part.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
