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
;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
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
f
ative. 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 Koppenho
://wiki.openstreetmap.org/wiki/Proposed_features/area:highway
flaimo
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
aw 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 re
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
. 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
f
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
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
>
ound) 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*
>
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/lis
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
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"
&
xample) 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 re
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 ot
on 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"
>
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
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
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
e.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&
ent 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
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
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
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
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
rega
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
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
> 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 s
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&q
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.
regar
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_se
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 1
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
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
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
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 -0
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
f
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
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
eaker 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
/Proposed_features/automated_tasks
flaimo
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
different addresses not
tied to any entrance.
regards,
flaimo
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
ag 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
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
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
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
_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/Propos
48 matches
Mail list logo
