Re: [Tagging] Reviving the conditions debate
With the access 1.5 and default opening_hours syntax it would look like this: define the rules for "forward" and "backward": • access!forwardrule.time=Mo-Fr 16:00-18:00 • access!forwardrule.direction=forward • access!backwardrule.time=Mo-Fr 06:00-09:00 • access!backwardrule.direction=backward apply them to motorized vehicles: • access:motorized?forwardrule=no • access:motorized?backwardrule=no define a more specific mode+role combination which outweights the rules applied to "motorized" • access:motorized&&agricultural=yes • access:motorized&&delivery=yes flaimo > Message: 8 > Date: Thu, 14 Jun 2012 08:38:52 +0200 > From: Colin Smale > To: tagging@openstreetmap.org > Subject: Re: [Tagging] Reviving the conditions debate > Message-ID: <4fd986fc.5070...@xs4all.nl> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Here's a test case. No motor vehicles mon-fri between 1600-1800 except > agricultural vehicles and good vehicles *in this direction*. Going the > other way the sign is similar but the times are between 0600 and 0900. > This is a short stretch of narrow road and the restrictions are intended > to stop commuters using it as a rat-run, while at the same time allowing > work to carry on as usual on the farms and businesses along that road. > > http://goo.gl/maps/ymvt ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
> Message: 2 > Date: Thu, 14 Jun 2012 10:31:17 +0200 > From: Martin Vonwald > To: "Tag discussion, strategy and related tools" > > Subject: Re: [Tagging] Reviving the conditions debate > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > I think I found a solution using a self-defined rule: > access:motor_vehicle!rule.time=10:00-18:00 > access:motor_vehicle!rule.width=5+ > access:motor_vehicle?rule=no > > Can this be simplified somehow (using the 1.5 proposal)? > > 2012/6/14 Martin Vonwald : >> Hi! >> >> Maybe someone can help me defining the following access restriction >> using the 1.5 proposal: >> http://wiki.openstreetmap.org/wiki/File:Length_and_time_restriction_2.jpg alternate version: access:motorized.time=Mo-Su 00:00-10:00,18:00-24:00 access!shortvehicle.length=5 access:motorized?shortvehicle.time=24/7 > Message: 4 > Date: Thu, 14 Jun 2012 10:53:33 +0200 > From: Martin Vonwald > To: "Tag discussion, strategy and related tools" > > Subject: Re: [Tagging] Reviving the conditions debate > Message-ID: > > Content-Type: text/plain; charset=windows-1252 > > I tried to express this with the other proposal. I got this: > motor_vehicle:(Mo-Fr 16:00-18:00):forward=no > agricultural:(Mo-Fr 16:00-18:00):forward=yes > goods:(Mo-Fr 16:00-18:00):forward=yes > > motor_vehicle:(Mo-Fr 06:00-09:00):forward=no > agricultural:(Mo-Fr 06:00-09:00):forward=no > goods:(Mo-Fr 06:00-09:00):forward=no > > I assume here, that agricultural and goods are more specific than > motor_vehicle. Any chance of simplifying this? this notation has the same flaw as the current access scheme. it mixes transportation modes and user roles. "motor_vehicle" is a transportation mode. "agricultural" is a user role. not everywhere on this planet "agricultural" automatically means "motor_vehicle". that is what the 1.5 proposal tries to solve. flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] access agricultural, WAS Re: Reviving the conditions debate
> Message: 4 > Date: Thu, 14 Jun 2012 16:45:28 +0200 > From: Martin Koppenhoefer > To: "Tag discussion, strategy and related tools" > > Subject: [Tagging] access agricultural, WAS Re: Reviving the > conditions debate > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > How can we resolve this? It seems obvious that we need either 2 tags > for agricultural (according to the legislation, either a vehicle class > or a use case is intended), or we accept that the same tag has > different meanings in different legislations/countries. Personally I > am in favour of an additional tag. We could also have 2 new tags: > "agricultural_use" and "agricultural_vehicle" to make it unambiguous, > and to deprecate the unclear agricultural. very easy. use the 1.5 proposal :-). for germany you could use access:motorized&&agricultural=yes. in developing countries, where motor vehicles are not common for most people, you could just use the role: access:agricultural=yes. That is the whole purpose of splitting user roles and transportation modes. and you don't run into the risk of a "germanification" of openstreetmap by always taking the german law or other western country laws as the basis for all tagging rules and leave out underrepresented countries. flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - Voting - building passage
the RFC phase was long enough. time to vote: https://wiki.openstreetmap.org/wiki/Proposed_features/building_passage flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] optimizing the payment tag
i would like to rewrite the wiki page for payment so there is a consistent payment:=yes/no scheme (like the fuel types for example). currently there is a mixture of boolean and list values which is not good for programmatic processing. i posted this to the comments of the page a couple of weeks ago, but got just one response, that was positive though. so i wanted to check with the tagging mailing list too. any suggestions or objections? flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - parking (redux)
since i wasn't the only one wondering on how to map individual parking spaces, i took the chance to write my first proposal. it's ready for comments and can be found here: http://wiki.openstreetmap.org/wiki/Proposed_features/parking regards flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking (redux)
i think you misread the proposal. you don't tag any capacity tags on a single parking space. and all common properties can also be defined in the relation, so no need to tag every single space either. Quote: "General tags ... defined in the relation are inherited by the elements inside the collection as long as not mapped otherwise." the naming for single spaces, as also the usage of the existing amenity=parking is already in discussion in the comments of the proposal. regards, flaimo On Fri, Mar 18, 2011 at 12:41, M∡rtin Koppenhoefer wrote: > > While I agree that mapping singular parking spaces is a valid desire, > I don't agree with the proposed tagging. To avoid confusion (and for > simplicity) I'd encourage to use a new tag for single lots. It is > ridiculous to add capacity=1, and other subtags on every single > parking space inside a bigger parking area. Instead amenity=parking > would be used for the whole parking facility and another (new) tag > like parking=lot (or whatever english wording is suitable) would be > used to indicate single spaces. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] optimizing the payment tag
maybe someone experienced with bots could write one that splits up payment:credit_cards=card_1;card_2;card_3 into payment:card_1=yes + payment:card_2=yes + payment:card_n=yes. same goes for payment:fuel_cards, payment:local_transport and other payment:=value;value;value tags. regards, flaimo > Message: 6 > Date: Fri, 18 Mar 2011 15:48:59 +1100 > From: David Murn > > Im in favour of this. Changing to a common boolean scheme such as that > makes it easier to answer yes/no questions when initially mapping, and > also easier to process. The only concern Id have would be migrating > from all the currently existing schemes to the new one, since payment is > in use more now than fueltypes was when that was suggested. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking (redux)
> Date: Fri, 18 Mar 2011 12:53:01 +0100 > From: Tobias Knerr > To: "Tag discussion, strategy and related tools" > > Subject: Re: [Tagging] Feature Proposal - RFC - parking (redux) > Message-ID: <4d83479d.5090...@tobias-knerr.de> > Content-Type: text/plain; charset=ISO-8859-1 > > I do not see a good reason to use amenity=parking on the individual > parking spaces within a larger parking area. Instead, I would prefer to > keep using amenity=parking a closed way that covers the entire parking > area and contains the individual parking spaces. I would then use a > different tag for individual parking spaces (parking_lot=yes if there > are no better ideas). Besides of requiring one tag less per feature, it > would not contradict current usage of amenity=parking, and would make it > a bit easier for renderers that want to ignore individual parking spaces > (which is a sensible cartographic decision for many use cases). my original version used new tags for all three elements, but a user in the comments suggested to explicitly use amenity=parking for compatibility reasons and to slowly force renderers to adapt this mapping scheme. > I also suggest to allow nodes for parking spaces. Areas are the obvious > choice *if* you use high-res satellite imagery. But without imagery, it > still makes sense to map individual parking spaces for special interest > groups from surveyed information. This is where a node is the > appropriate solution until more detailed data becomes available. > Accepting both nodes and areas to accommodate different detail levels of > data is good practice for other features, e.g. those in the shop and > amenity categories. good argument. i changed the proposal accordingly. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking (redux)
On Fri, Mar 18, 2011 at 13:27, M∡rtin Koppenhoefer wrote: > 2011/3/18 Flaimo : > > IMHO no need for a relation, as the amenity=parking around it already > gives you this information. You would "need" the capacity if you won't > differentiate between "area" (several parking spaces) and "space" (one > parking space), which I'd encourage (it is the same feature, just > differing in size/capacity, so better use just one tag instead of 2 > IMHO). i don't agree with that, because only the physical areas where, for example a car, can park is a parking space/area, but not for example the street itself. the current mapping scheme by using a big area over the whole parking facility is just inaccurate and comes from times where mappers didn't have satellite images available and couldn't accurately map such areas. what you actually would need is a landuse=parking and a amenity=parking. the first describes the whole parking facility, the second the actual parking spaces. take this parking lot for example: http://osm.org/go/0JhJenH8g-- . how should a renderer or routing programm know, that those individual parking spaces actually are one big lot? that's the whole purpose of the proposal, so a more accurate mapping of the individual elements is possible. if you want to use the current inaccurate mapping scheme you can still do that by not using don't use parking_type and a relation. regards, flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking (redux)
ok, i see what you mean now. use amenity=parking for the whole facility, and the new tags for defining the elements inside. that only works without a relation as long as you only have one logical parking lot that's not split up in different areas. but parking lots, on airports for example, are often separated by official roads which are not part of the parking lot. therefore you would map two amenity=parking areas and then you need the relation anyway. and what about situations where parts of the area are not part of amenity=parking? exclude them by creating a multipolygon relation for that spot? doesn't make things easier. also inheritance of properties would be more complicated in the long run. that's exactly why the relation=site proposal was written (which, according to the comments, is already used a lot) and why i based my proposal on that. i'll mention your concern in the comments of the proposal and let's see what the other users think. on terms of the interpretation of amenity=parking. i don't see why the purpose couldn't be further refined by an additional tag. it is done this way for highway=service + service=* for example. regards, flaimo On Fri, Mar 18, 2011 at 14:09, M∡rtin Koppenhoefer wrote: > > Yes, but the streets that are exclusively used to access the parking > space are part of the parking. The latter is what amenity=parking is > about, (see also in combination with parking=surface, underground, > multilevel), the first is what you want to tag. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking (redux)
On Fri, Mar 18, 2011 at 15:51, M∡rtin Koppenhoefer wrote: > 2011/3/18 Flaimo : > I don't understand this. Inheritance of properties is implicit in > multipolygon relations. take a look at the example for the car rental: http://wiki.openstreetmap.org/wiki/File:Big_car_rental_service.png it's about inheriting general values defined in the relations and subrelations. i think with just a multipolygon this is not possible. but i actually consider multipolygon relations more complicated to understand than the site relation. just relying on a surrounding amenity=parking area without a relation also has another flaw: underground parking. basically nobody maps underground parking facilities as areas with layer=-1. all of those i have seen so far in OSM are mapped as nodes at the entrances. and that is the problem. underground parking facilities often have more than one entrance. right now, each entrance is interpreted as its own parking lot. the relation would group them together to one parking facility. > the site relation is indeed used a lot (around 128.000 times) but IMHO > needed only for details like where is the ticket office, where is the > main entrance, which would be a suggested label position (render > hint), etc. and there is no application that I know of (in contrary to > multipoly) which takes site relations into account. labeling position is not mentioned in the parking proposal and i also don't think that it is important right now. it would be a nice benefit, though. also the site relation for parking could be part of a bigger site relation which would represent a consistent mapping stile. that nobody interprets it is not the mappers or the mapping schemes fault. sticking with an older and, in my opinion, less suitable method, because map and routing programmers don't keep up with new developments, shouldn't be the way to go. otherwise we still wouldn't have the new public transport scheme, which also is also used a lot and still isn't interpreted in mapnik. regards, flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking (redux)
service roads are not explicitly part of the proposal, but can be added to the relation. quote fro the proposal: "Other elements, that are of interest, can also be added to the relation. For example: ticket vending machines, emergency phones, a.s.o" flaimo > Date: Tue, 22 Mar 2011 12:02:06 +1100 > From: David Murn > To: "Tag discussion, strategy and related tools" > > Subject: Re: [Tagging] Feature Proposal - RFC - parking (redux) > Message-ID: <1300755727.3701.41.camel@grunge> > Content-Type: text/plain; charset="UTF-8" > > In the case of the roads inside a parking area, there already exists > highway=service, service=parking_aisle. > > http://wiki.openstreetmap.org/wiki/Tag:service%3Dparking_aisle > > Have you considered the existing use of these tags in your proposal? > > David ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking (redux)
since there haven't been any new comments over the last couple of days i would like to start the voting for the proposal next weekend. here's the link again in case you haven't read it yet: http://wiki.openstreetmap.org/wiki/Proposed_features/parking regards, flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking (redux)
On Mon, Apr 11, 2011 at 01:15, M∡rtin Koppenhoefer wrote: > I am not sure if it is a good idea to put all these new tags into the > amenity namespace. Amenities are "general" features (e.g. mapnik tries > to render all of them) and the proposed tags like parking_space would > in a complete mapping state clutter the map. i think, that it doesn't really matter under which key parking spaces and entrances are mapped. which one would you suggest? the parking key is already taken. > If I get this right you suggest to consider amenity=parking as > preliminary and to replace it with amenity=parking_space for single > parking lots or groups of them, connected with relations? you can use amenity=parking_space it, but you don't have to. as stated in the proposal there are situations where it is actually not possible to do detailed mapping. that's when you should continue to use the current amenity=parking. > I think this is too complicated for most cases. as stated in the proposal, it is meant for complicated parking situations, not every single parking lot. you can use it though if you like to do detailed mapping. it is definitely easier to understand, than for example the proposal for public transport which is already widely used. >I suggest to continue > the use of an area with amenity=parking for outline of the whole > facility and optionally parking=parking_space for single or groups of > actual parking spaces (plus optionally all subtags for all kind of > details as suggested). as mentioned in previous mails as also in the proposal, areas for grouping don't work out. > maybe it would be easier to split this up in 2 proposals: one for > parking_spaces and one for complex parking relations. > while you could use amenity=parking_space for itself, amenity=parking_entrance doesn't make much sense without the context of the relation which holds the information of the actual (underground) parking facility. if you want to use amenity=parking_space without a relation, you could do so, but then you could stick with amenity=parking anyway. regards, flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] your opinion on a delete/change key
recently i stumbled across one of my edits i did over a year ago. i mapped a new house with building=construction and the area around it with landuse=construction. i totally forgot about that, and since there don't seem to be any other mappers close by, nobody removed the construction tag even though the house has been finished a long time ago. so i thought, maybe it would be nice to have some tags to handle situations like this: 1) delete = elements (node, way, area, relation) tagged with this key could be deleted after the date given (as long as they don't share any data with other elements) 2) delete: = same as the key above, but only deletes the line for the referenced key (if it still exists at the time) change: = 2011-04-11T12:22:22; same as delete:, but instead of deleting the line it would change the value for the referenced key. if the key doesn't yes exists or doesn't exists anymore, it gets added. so in my case i would have added a "delete=2011-01-31T00:00:00" to the area tagged with landuse=construction (which was over a bigger landuse=residential area) and a change:building=2011-01-31T00:00:00;house to the building, which at that point was still tagged with building=construction. bots then could check the database on a daily basis for those tags and delete/change them accordingly. what's your opinion on that? if the overall response is positive, i could start a proposal for it. flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] your opinion on a delete/change key
i think that is to vague. a user should have an idea, what happens, when he uses the tag. "reinsprect" can mean everything from "it will be deleted" to "nice, but nobody is going to touch this". also for finished constructions i wouldn't invent a new tag. if the construction is estimated to be finished in 2 months, i would just add a grace period of one additional month and then use "change:highway=;residential" to change the currenten value from "construction" to "residential" flaimo > Date: Fri, 15 Apr 2011 16:43:03 -0400 > From: Richard Welty > To: tagging@openstreetmap.org > Subject: Re: [Tagging] your opinion on a delete/change key > Message-ID: <4da8add7.1000...@averillpark.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 4/15/11 4:18 PM, Josh Doe wrote: >> I'm not sure if I'd call it delete, maybe something more verbose and >> general like "reinspect_date". This would be useful for some highway >> construction projects I've added which have given an estimated date of >> completion. > yes, reinspect_date might be useful. although there might be other > types of date, so maybe > > date:reinspect > date:projected:construction_end > ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - amenity=recycling_centre
Currently fellow mappers use amenity=recycling to map anything from small paper/plastic containers up to big recycling centres. This vague definitions is a problem for renderers as for routing programs, since they can't differentiate between those two, even though centres are more important than the small containers (which are used basically everywhere in countries that have a distinct recycling program). That is why I wrote a small proposal for this new amenity value which can be found here: http://wiki.openstreetmap.org/wiki/Proposed_features/recycling_centre flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - Voting - parking (redux)
since no new input came in over the last week after my second RFC mail, i started the voting phase for http://wiki.openstreetmap.org/wiki/Proposed_features/parking regards, flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - daycare
created a proposal for amenity=daycare: http://wiki.openstreetmap.org/wiki/Proposed_features/daycare more information on wikipedia: http://en.wikipedia.org/wiki/Daycare flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - daycare
i have changed the value from daycare to childcare, added a list of some additional tags that can be used and rephrased the definition a little bit, though i think it will never quite satisfy the different definitions in every country. i definitely didn't meant it to be a general tag which also includes elderly people or call centres for home based care taking. the later one should rather be tagged with office=*. the way i intended it, it is as a place where children go to after school to do homework and then play until their parents with full time jobs can pick them up. if a native speaker could give a more precise definition, then the current one i use in the proposal, i would appreciate it. regards, flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Fwd: Feature Proposal - RFC - automated tasks
i have started a proposal for simple automated tasks. i will leave it in the RFC state until someone, who knows how to create a bot, can provide a prototype for a small imited bbox, so we can see if this one is actually doable (performance and security wise). http://wiki.openstreetmap.org/wiki/Proposed_features/automated_tasks flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - associatedAddress
http://wiki.openstreetmap.org/wiki/Proposed_features/associatedAddress coincidentally the author of associatedEntrance seems to have stumbled across the same kind of problem and has written a proposal at the same day as i did. but after going through his proposal, there is a difference: while his proposal deals with connecting POIs to physical entrances, mine tries to solve the problem for address objects. both are not the same, and are also not mutually exclusive. there are situations where you need to use both proposals at the same time. for example a shopping mall with 6 entrances and 3 different addresses not tied to any entrance. regards, flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fwd: Feature Proposal - RFC - automated tasks
> Date: Sun, 24 Apr 2011 10:41:12 -0400 > From: Serge Wroclawski > Subject: Re: [Tagging] Fwd: Feature Proposal - RFC - automated tasks > > I think the number of tags in this kind of proposal would balloon > quickly, so let me suggest instead that tags of this nature be put on > the changeset, with a then request to bot authors to check object > history and changesets, rather than more tags on the object. > > In other words, use the changeset to hold this (what I think of as) > metadata, rather than the object itself. i don't understand on how that would be the case. after execution of the task the corresponding tag gets deleted anyway since they are only temporarily. i can't see on how changesets should be better. you would have to start a changeset per deadline and that's even more complicated, since it cannot be done easily within tag editors. also fellow mappers would never know that someone else already has a changeset prepared, since mostly people check the tags only. flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - addr keys (2011-04)
http://wiki.openstreetmap.org/wiki/Proposed_features/addr_keys_%282011-04%29 my fourth proposal within 7 days :-) flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addr keys (2011-04)
> Date: Mon, 25 Apr 2011 15:51:14 +0100 > From: Jerry Clough : SK53 on OSM > Subject: Re: [Tagging] Feature Proposal - RFC - addr keys (2011-04) > > I suspect that there are too many local variants to handle. in parts, that is also my optinion. that is why i didn't call it suite or something like that, but also because of following reasons: 1) whats behind a door or entrance can be something else than just a suite 2) plain english words are also more easily understood by non native speakers 3) it doesn't favor the british or american way of naming things if it gets approved i would suggest to put the different notations used in each country in the description column of the addr wiki page (or the localized version of the wiki page). flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - shelter type
http://wiki.openstreetmap.org/wiki/Proposed_features/shelter_type the main reason for this proposal is this trac ticket: http://trac.openstreetmap.org/ticket/3346 regards, flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - Voting - parking (redux) [2nd call]
voting ends in two days. though the overall response is positive, voter participation is still low. so if you haven't voted yet, i would encourage you to do so. for those, who don't want to go through the whole lengthy proposal, here is the outline: two new amenity values: parking_space and parking_entrance. tied together with a standard site relation. flaimo On Sun, Apr 17, 2011 at 17:10, Flaimo wrote: > since no new input came in over the last week after my second RFC > mail, i started the voting phase for > http://wiki.openstreetmap.org/wiki/Proposed_features/parking ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - Voting - recycling type
no new input recently in the comments. also it is just one key with two possible values, so i guess there is not a lot to talk about. that is why it is up for voting now: http://wiki.openstreetmap.org/wiki/Proposed_features/recycling_type regards, flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - Access restrictions 1.5
another/my take on the access /conditions topic. started out as a comment, but when it became longer, i decided to put it on it's own proposal page. also, the other proposals about access topics seem abandoned, so i thought i give it another try. it is rather long, so it probably isn't a quick read during lunch break: http://wiki.openstreetmap.org/wiki/Proposed_features/access_restrictions_1.5 flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - Voting - childcare
no further comments over the last 1 1/2 weeks, so i'll start the voting phase: http://wiki.openstreetmap.org/wiki/Proposed_features/childcare btw my other proposal could still need some votes: http://wiki.openstreetmap.org/wiki/Proposed_features/recycling_type flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging] Feature Proposal - Voting - childcare
as stated in the proposal, childcare is not the same as kindergarden. it is something children go to after school (and sometimes after kindergarden) to fill the time gap between the end of school and the time parents with a full time job can take care of them. in some countries this isn't necessary, since school goes to late in the afternoon anyway and afterwards the children are brought home by school buses directly. but in other countries school often ends around noon and that is where this kind of facilities fill the gap. Further, i too consider the social facility tags to negative. Besides that, i couldn't see a social_facility=* value that would fit. the "or=child" part references to an target audience, which would correspond more to the "age" tag of my proposal and not the amenity=childcare. flaimo On Mon, May 9, 2011 at 12:14 PM, M∡rtin Koppenhoefer wrote: > 2011/5/8 Flaimo : > The biggest issue I see is that this feature seems already be covered > by the social facility feature: > http://wiki.openstreetmap.org/wiki/Social_facility > Have a look at the subkey social_facility:for=child e.g. daycare > center for children That page has a not so nice undertone of "help the poor", so I'm reluctant to tag my amenity=kindergarten as a social_facility even though it really is a "social facility". So maybe I should help to expand it to be more about social and less about "social outreach", but I would still tag most daycares as kindergarten: http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dkindergarten Obviously it's hard to describe daycare since it varies so much from country to country, but the proposals don't seem to touch many of the aspects brought up when you asked for comments the last time. http://www.mail-archive.com/tagging@openstreetmap.org/msg07353.html open_hours is not even usefull to map around here since it can mean so many different things. amenity=kindergarten religion=scientology age=1-6 ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - area:highway
it has been brought up a couple of times in the german forums, so it seems there is a need for mapping the dimensions of roads (similar to riverbanks for rivers). the tag itself was suggested by another user, but i thought it would be a good idea to put it into a dedicated proposal. http://wiki.openstreetmap.org/wiki/Proposed_features/area:highway flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - area:highway
you misread that. because if its imprecise definition, there are still heated discussions on how detailed landuses should be mapped. some leave out the areas of the streets, some don't. all i wanted to state out is, that this isn't a part of the area:highway proposal. if you want to draw it over landuses you can do so, but if you are part of the other fraction you can connect it to landuses. I'm not taking sides with this proposal. flaimo > Message: 7 > Date: Wed, 11 May 2011 13:58:45 +0200 > From: M?rtin Koppenhoefer > To: "Tag discussion, strategy and related tools" > > Subject: Re: [Tagging] Feature Proposal - RFC - area:highway > Message-ID: > Content-Type: text/plain; charset=UTF-8 > > 2011/5/11 Nathan Edgars II : >> The proposal makes reference to landuse, in particular stating that one >> might cut off adjacent landuses at its border. But the two positions on >> landuse are that it shouldn't be cut or that it should be cut at the >> right-of-way line, not at the edge of the roadway. > > > +1, you're right > I overlooked this. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - area:highway
that is perfectly possible with area:highway. just tag the road area:highway=residential for example and the other area:highway=footway. all values from the highway key are possible (at least from the roads or paths category). flaimo > Message: 7 > Date: Wed, 11 May 2011 17:36:04 +0200 > From: Simone Saviolo > To: "Tag discussion, strategy and related tools" > > Subject: Re: [Tagging] Feature Proposal - RFC - area:highway > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > I understand it's debatable whether to include the sidewalk into the > area:highway object. I think it should ideally be given a different object. > If we agree that sidewalks should be mapped as linear highway=footway (I > know there's discussion on this point, I'm making a supposition), then we > should have two different area features (or multipolys or whatever), one > with area:highway=unclassified/residential/whatever and another one with > area:highway=footway. In simpler terms, I wouldn't use area:highway to cover > the whole right-of-way area. > ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - voting - childcare
there was a lot of discussion going on over the last two days for this proposal, but still hardly anyone voted. i think it would be a good idea if everyone who took part in the discussion would vote, so that we at least get an impression on the tendency for or against the childcare value. currently there are only five (positive) votes which isn't a lot. i could also live with the social_facility value in case it gets declined, but i would like to see a meaningful result in the votes. http://wiki.openstreetmap.org/wiki/Proposed_features/childcare#Voting flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - voting - childcare
i changed the main key to service_times, but i kept the subkey. otherwise it would be problematic in case someone want to tag the office hours separately. flaimo > Message: 6 > Date: Thu, 12 May 2011 01:15:26 +0200 > From: M?rtin Koppenhoefer > To: "Tag discussion, strategy and related tools" > > Subject: Re: [Tagging] Feature Proposal - voting - childcare > Message-ID: > Content-Type: text/plain; charset=UTF-8 > > 2011/5/11 Flaimo : >> http://wiki.openstreetmap.org/wiki/Proposed_features/childcare#Voting > > > I don't see why there should be "service_hours:childcare". Can't we > reuse service_times? > http://wiki.openstreetmap.org/wiki/Key:service_times ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] website=*url* vs. contact:website=*url*
the reason for that might be, than no editor supports the contact: syntax. personally, i always use it and type it in manually without the JOSM preset, because it makes locating all the contact information in long tag lists much easier. same goes for addr:, payment: and fuel: hopefully in the future, when tag list tend to become longer and have to be scrolled all the time, editors implement some sort of collapse feature for namespaces. so +1 for "contact:" from me. flaimo > -- > > Message: 8 > Date: Thu, 12 May 2011 09:10:43 -0700 > From: Sam Vekemans > To: "Tag discussion, strategy and related tools" > > Subject: [Tagging] website=*url* vs. contact:website=*url* > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > http://wiki.openstreetmap.org/wiki/Key:contact:website > http://wiki.openstreetmap.org/wiki/Key:website > > According to taginfo, the former isn't used much... and in JOSM i havent yet > seen it actually used.. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] website=*url* vs. contact:website=*url*
when was the topic of webcams ever mentioned? they have nothing to do with this topic. also we are not talking about what counts as a contact information and what not. pretty much everybody agrees that phone, fax, e-mail and website are seen as contact information, probably because millions of people put those on their business cards. the topic is whether to use the contact namespace for those (four) keys or not. the numbers you list are like that because, as i mentioned before, most use the presets for tagging. if the presets would be changed to use the contact: prefix, the situation would be exactly the contrary in two years. so we should list advantages and disadvantages of a namespace and think about if it might make sense to group them under "contact:" in the future by modifying the presets. existing tag could easily be changed to the namespace (or the other way around) by a simple one time batch job in the database. flaimo > Message: 4 > Date: Thu, 12 May 2011 20:26:46 +0200 > From: M?rtin Koppenhoefer > To: "Tag discussion, strategy and related tools" > > Subject: Re: [Tagging] website=*url* vs. contact:website=*url* > Message-ID: > Content-Type: text/plain; charset=UTF-8 > > > OSM allows everybody to tag whatever he likes, which is great. Still I > don't think that a website is "contact"-information, like a phone > number is. Neither has "contact:webcam" anything to do with "contact". > Actual usage shows that the whole "contact" is a typical "wiki > stillbirth": > > 108398 website (wiki page created 20:17, 3 April 2008 ) > 240537 url (wiki page created 23:19, 8 May 2008 ) > 4332 contact:website (wiki page created 08:06, 22 January 2009 ) > > For the disputed phonenumbers (many mappers argue that phonenumbers > are no geoinformation) the situation is similar: > 88147 phone > 9015 contact:phone > > Btw.: there is (still) 0 contact:addr:street and 0 > contact:addr:housenumber in the database. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addr keys (2011-04)
any other comments on that proposal? otherwise i'll start the voting phase: http://wiki.openstreetmap.org/wiki/Proposed_features/addr_keys_%282011-04%29 flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - Voting - shelter type
open for voting now: http://wiki.openstreetmap.org/wiki/Proposed_features/shelter_type regards, flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addr keys (2011-04)
something like that should be handled in a seperate proposal, though i think most of your examples are covered with addr:housename. flaimo > Message: 1 > Date: Mon, 16 May 2011 13:36:39 +0200 > From: M?rtin Koppenhoefer > To: "Tag discussion, strategy and related tools" > > Subject: Re: [Tagging] Feature Proposal - RFC - addr keys (2011-04) > Message-ID: > Content-Type: text/plain; charset=UTF-8 > > Yes. You are currently concentrating on the micro level, but there > could be a suggestion for the intermediate scale between the whole > complex and the micro level as well: de:"Hof" (engl. "courtyard") > > This is often also expressed indirectly in addresses with the German > terms "Seitenfl?gel" (side wing), "Vorderhaus" (front building), > "Hinterhaus" (rear building), "2. Hinterhaus" (second rear building = > 2nd courtyard rear building), etc.) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - shelter type
> Message: 5 > Date: Tue, 17 May 2011 16:49:43 +0200 > From: fly > To: "Tag discussion, strategy and related tools" > > Subject: Re: [Tagging] Feature Proposal - Voting - shelter type > Message-ID: <4dd28b07.7030...@googlemail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Please, do not mix hunting_stands with shelter. > > Many hunting_stands do not even have a roof nor walls. > Many are only reached by climbing up a latter. hunting stand is just an example someone gave in the comments. it is not really part of the proposal. if approved i probably won't put it on the dedicated wiki page. > shelter=yes or shelter=* could be a solution to think about. that won't work. shelter=yes is already a sidecar tag mapped on an element with another main key, that is not a shelter (like highway=platform for example) to indicate that there is a shelter somewhere, but cannot be exactly pinpointed (because for lack of satellite images). i can't just go and give it a completely different meaning of a refinement tag for an element mapped with amenity=shelter. that is also one of the reasons why i didn't use "recycling" in my recycling_type proposal. flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - Voting - addr keys (2011-04)
removed addr:entrance and addr:room since they were too controversial and changed addr:staircase to more versatile addr:unit. voting is now open: http://wiki.openstreetmap.org/wiki/Proposed_features/addr_keys_%282011-04%29 flaimo On Sat, May 14, 2011 at 11:47, Flaimo wrote: > any other comments on that proposal? otherwise i'll start the voting phase: > > http://wiki.openstreetmap.org/wiki/Proposed_features/addr_keys_%282011-04%29 > > flaimo > ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] access=avoid
the wiki page doesn't say that the restriction need to be of a legal kind. access=no could also mean that it is physically not accessible even though it might be allowed legally. on the other hand, i don't see "avoid" as a value, but rather as some sort of additional information like "description". so, just like "wheelchair:description", you could use "hgv:avoid=yes/no". flaimo > Message: 5 > Date: Tue, 14 Jun 2011 11:47:26 +0200 > From: M?rtin Koppenhoefer > To: "Tag discussion, strategy and related tools" > > Subject: Re: [Tagging] access=avoid > Message-ID: > Content-Type: text/plain; charset=UTF-8 > > you are actually missusing the access-tag because it is intended for > legal restrictions and not for recommendations. Why not use another > tag? Their number is not limited... ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - organic/fair_trade
see http://wiki.openstreetmap.org/wiki/Proposed_features/organic any comments or suggestion can be added to the talk page of the proposal regards, flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - building_passage
https://wiki.openstreetmap.org/wiki/Proposed_features/building_passage any comments or suggestion can be added to the talk page of the proposal regards, flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - Voting - organic
now open for voting: http://wiki.openstreetmap.org/wiki/Proposed_features/organic flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
