[Tagging] optimizing the payment tag
i would like to rewrite the wiki page for payment so there is a consistent payment:payment method=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 dieterdre...@gmail.com 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:x=value;value;value tags. regards, flaimo Message: 6 Date: Fri, 18 Mar 2011 15:48:59 +1100 From: David Murn da...@incanberra.com.au 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 o...@tobias-knerr.de To: Tag discussion, strategy and related tools tagging@openstreetmap.org 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 dieterdre...@gmail.com wrote: 2011/3/18 Flaimo fla...@gmail.com: 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 dieterdre...@gmail.com 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 dieterdre...@gmail.com wrote: 2011/3/18 Flaimo fla...@gmail.com: 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 da...@incanberra.com.au To: Tag discussion, strategy and related tools tagging@openstreetmap.org 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 dieterdre...@gmail.com 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 = ISO datetime 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:Key = ISO date same as the key above, but only deletes the line for the referenced key (if it still exists at the time) change:Key = 2011-04-11T12:22:22;Value same as delete:Key, 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
[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
[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 emac...@gmail.com 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 sk53_...@yahoo.co.uk 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 fla...@gmail.com 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
[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
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 simone.savi...@gmail.com To: Tag discussion, strategy and related tools tagging@openstreetmap.org Subject: Re: [Tagging] Feature Proposal - RFC - area:highway Message-ID: banlktinwgnh6t0zntxoh3m3dvwnytao...@mail.gmail.com 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 dieterdre...@gmail.com To: Tag discussion, strategy and related tools tagging@openstreetmap.org Subject: Re: [Tagging] Feature Proposal - voting - childcare Message-ID: BANLkTi=ppc1iyporccpzk5vor-yvjre...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 2011/5/11 Flaimo fla...@gmail.com: 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 acrosscanadatra...@gmail.com To: Tag discussion, strategy and related tools tagging@openstreetmap.org Subject: [Tagging] website=*url* vs. contact:website=*url* Message-ID: banlktimpac2nubz5bkvkwr12bj3bmpq...@mail.gmail.com 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 dieterdre...@gmail.com To: Tag discussion, strategy and related tools tagging@openstreetmap.org Subject: Re: [Tagging] website=*url* vs. contact:website=*url* Message-ID: BANLkTi=7lnrpmvmzjsbqoyg-cqm3qdw...@mail.gmail.com 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
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 dieterdre...@gmail.com To: Tag discussion, strategy and related tools tagging@openstreetmap.org Subject: Re: [Tagging] Feature Proposal - RFC - addr keys (2011-04) Message-ID: banlktiml-_p8ayomvpgg26jjydfmcoo...@mail.gmail.com 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
[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 fla...@gmail.com 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 dieterdre...@gmail.com To: Tag discussion, strategy and related tools tagging@openstreetmap.org Subject: Re: [Tagging] access=avoid Message-ID: BANLkTi=wtlkpnb2ruv+nh6u8prgf2ya...@mail.gmail.com 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
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:motorizedagricultural=yes • access:motorizeddelivery=yes flaimo Message: 8 Date: Thu, 14 Jun 2012 08:38:52 +0200 From: Colin Smale colin.sm...@xs4all.nl 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 imagic@gmail.com To: Tag discussion, strategy and related tools tagging@openstreetmap.org Subject: Re: [Tagging] Reviving the conditions debate Message-ID: cakjckynqkfsxhltureutycfm9drjwmcxbx9sgocgy61qw2s...@mail.gmail.com 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 imagic@gmail.com: 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 imagic@gmail.com To: Tag discussion, strategy and related tools tagging@openstreetmap.org Subject: Re: [Tagging] Reviving the conditions debate Message-ID: cakjckymigho-wu20ya8wvco7u8pjrds7+ngickdotvvvufk...@mail.gmail.com 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 dieterdre...@gmail.com To: Tag discussion, strategy and related tools tagging@openstreetmap.org Subject: [Tagging] access agricultural, WAS Re: Reviving the conditions debate Message-ID: CABPTjTC42=+em2ag9qax7btnm60eaujtak3bfx-aa9_cahj...@mail.gmail.com 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:motorizedagricultural=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
