Re: [Tagging] OHV greater than 50 inches (wide)

2020-09-02 Thread Robert Whittaker (OSM lists)
On Tue, 1 Sep 2020 at 21:33, Mike Thompson  wrote:
> In specifying access constraints for the roads it manages, the US Forest 
> service makes a distinction between ATVs, highway vehicles, and "OHVs > 50"."
> The first two categories correspond to the tags motorcar=* and atv=* I think, 
> but I have not been able to find an existing tag that corresponds to "OHVs > 
> 50"."  There is an ohv=* tag, but it seems to apply to all OHVs regardless of 
> width as well as motorcycles.

Have you looked at conditional access restrictions:
https://wiki.openstreetmap.org/wiki/Conditional_restrictions ?

If ohv=* is understood as an access tag (though it doesn't appear at
https://wiki.openstreetmap.org/wiki/Key:access ), then you could e.g.
do something like ohv = no + ohv:conditional = yes @ (width > 50") to
allow OHVs only if they are wider than 50".

-- 
Robert Whittaker

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Addresses with PO Box, and other delivery type addresses.

2020-03-19 Thread Robert Whittaker (OSM lists)
On Thu, 19 Mar 2020 at 14:43, Tobias Wrede  wrote:
> Isn't the addr:* scheme used to describe the physical address of a 
> location/building/amentiy/etc.?
>
> PO Boxes, privat bags etc. are addresses where mail for someone residing at 
> said location is delivered to.
>
> As addr:* I would always put in what is needed to find the place as a visitor 
> and that is a housenumber and street, a house name or any other place name. 
> And sometimes there might be nothing besides city or postcode.
>
> Mail delivery address I would expect to find under the contact:* scheme if at 
> all.

Those would be my thoughts too.

Robert

-- 
Robert Whittaker

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Public refrigerators

2020-02-25 Thread Robert Whittaker (OSM lists)
On Tue, 25 Feb 2020 at 15:47, Markus  wrote:
> I've noticed that recycling:food= has been added [1] to
> amenity=recycling wiki page with the meaning "community fridge [2] to
> help reduce food waste".
>
> [1]: 
> https://wiki.openstreetmap.org/w/index.php?title=Tag:amenity%3Drecycling=1908674=1906084
> [2]: https://en.wikipedia.org/wiki/Community_fridge
>
> In my opinion, it's not a good idea to tag community fridges (public
> refrigerators) amenity=recycling, because containers for recycling or
> reuse are only for depositing and not for picking up. What if there
> are also containers where food can only be deposited, but not picked
> up (similar to containers for clothing donations)? We couldn't tell
> them apart any more.
>
> As we already use amenity=public_bookcase and amenity=give_box for two
> very similar facilities, it seems better to use something like
> amenity=public_refrigerator or amenity=community_fridge.

I agree with your thoughts re not using amenity=recycling. I've tagged
a couple of Community Fridges near me as

amenity=social_facility + social_facility=community_fridge

as this tagging (although not documented anywhere) mirrors that for
Clothing Banks, Food Banks and Soup Kitchens, which are listed at
https://wiki.openstreetmap.org/wiki/Key:social facility , and seem to
be related sorts of things. (Though I'm not sure how much these
community fridges are designed to provide useful items for those in
need, versus just help reduce waste versus. The balance is probably
slightly different for each implementation.)

Robert.

-- 
Robert Whittaker

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Deprecating of leisure=common and leisure=village_green

2017-12-01 Thread Robert Whittaker (OSM lists)
On 30 November 2017 at 22:45, Daniel Koć  wrote:
> While making some cleaning in osm-carto we have found that leisure=common
> and leisure=village_green are probably not clear enough to show them any
> more. They both have deep roots in British law and history and are
> frequently misused, as far as I can tell.

I agree that those two leisure keys are somewhat odd, as they appear
to be based on a legal designation rather than physical
characteristics. However, that's probably not the full story in the
UK, as they're likely to be used for patches of land that have the
appearance of a typical common or village green, and thus would be
recognised as such by most residents, even if legally they're not. The
"village green" and "common" terms can be thought of as comparable to
other names for open spaces such as "recreation ground" and "park",
but distinct from a UK point of view. Some legal village greens and
commons could well be "recreation grounds" and some may be "parks" but
many will not be either in the British English usage sense.

To capture the legal designation of patches of land, I would recommend
using the designation=* key, with something like
designation=common_land and designation=village_green. (However, we
probably wouldn't want to automagically add these tags to all UK
leisure=common and leisure=village_green objects, as some of the uses
may be based on appearance and not legal status.) Access tags can also
be added to describe access rights. But in addition to this, we'd need
something to capture the physical state / utility of the area. Often
neither leisure=recreation ground nor leisure=park will fit the bill.
If not, then natural=heath, natural=grassland, or natural=meadow may
fit the bill for commons, but it would be a shame if we didn't have
something specific for village green type areas of maintained grass.

In conclusion, I think there are reasonable arguments in favour or
replacing leisure=common with more appropriate tags to describe the
legal status, physical condition and access rights. But I'm not sure
about village_green, as there's a physical/utility aspect captured
there that I think should be maintained, and I'm not sure that there's
an alternative tagging available at the moment.

Robert.

-- 
Robert Whittaker

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] A place where letters & parcels are sent to be sorted so they can be delivered?

2017-02-23 Thread Robert Whittaker (OSM lists)
On 22 February 2017 at 19:56, Dave F  wrote:
> A place where letters & parcels are sent to be sorted so they can then be
> delivered?
>
> In the Britain I think they'd normally be called a sorting office. but
> there's only 21 & 2 for postal_sorting_office from tag info
>
> Is post_depot the same thing? (313 wordwide/212 GB)
>
> Either tag doesn't seem a great number. Is there a more popular one in use?

I've used amenity=post_depot quite a few times in the UK to mean
precisely that. (In particular, I needed something to re-tag Royal
Mail buildings to show that they weren't an amenity=post_office.)
I chose post_depot as a more general term, that would be applicable to
things that might be called a "Delivery Office", a "Sorting Office" or
maybe even something like "Parcel Hub" or "Distribution Centre". The
initial "post_" part mirrored existing "post_office" tag.

Robert.

-- 
Robert Whittaker

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Subject: Feature Proposal - RFC - highway=social_path

2016-06-15 Thread Robert Whittaker (OSM lists)
On 15 June 2016 at 13:10, John Willis  wrote:
> Why isn't having a footway=trail subtag (or something) seen as a much more
> reliable solution?

Perhaps more of an aside, but it may explain some people's reluctance
/ confusion with highway=trail:

As a native British English speaker, the word I would use for what I
think you're describing as a "trail" (i.e. a rough path through the
countryside that's used as a route by walkers / hikers) is "path" or
"footpath" (or maybe "track" if it was wider) -- which are the same
words that I'd use for paths through a park. I would normally use the
word "trail" to describe a route rather than the path itself,
particularly if there was some other purpose/interest in the route
(cultural, historic, fitness, wildlife) above than just walking the
paths.

But back on topic, if two paths have identical surface and width
characteristics (which we can already tag), what difference does it
make whether it's through a park or across more open countryside? Why
would it matter to data consumers or renderers?

Robert.

-- 
Robert Whittaker

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Tagging village sign

2015-05-08 Thread Robert Whittaker (OSM lists)
On 7 May 2015 at 23:11, pmailkeey . pmailk...@googlemail.com wrote:
 Tips on tagging a village sign please.

 Village sign: an ornate sign located fairly central to the village - such as
 on the village green.

There are lots of these signs near where I live. See
http://en.wikipedia.org/wiki/Village_sign for examples.

I've always used man_made=village_sign to tag them -- which seems to
have a number of uses according to
http://taginfo.openstreetmap.org/search?q=village+sign#values
(although a good proportional of them are probably down to me).

The village name shown on the sign should also be recorded, and for
that I've used name=*. I know that perhaps doesn't quite fit with the
usual use of name=*, as here it's the name being shown, rather than
the name of the sign, but I thought it was close enough. But if anyone
has any better suggestions there...

Robert.

-- 
Robert Whittaker

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Change in rendering in Mapnik of Nature Reserves.

2014-07-24 Thread Robert Whittaker (OSM lists)
On 24 July 2014 00:10, Dave F. dave...@madasafish.com wrote:
 Thanks for pointing that out to me. As I said, I personally had no problem
 with 'NR' but I'd be OK with it's removal is there was some king of infill.
 ATM there is none  it looks virtually invisible.

I'm not sure if this is in the right place, but I've previously added
some comments to the commit that implemented the changes:
https://github.com/gravitystorm/openstreetmap-carto/commit/3e5cbea1413ef2fea0d43bffee51c39d940a4c6d

In short -- I think we need an area-based rendering to make these
visible. But at higher zooms, a shading probably won't work very well
over other landuse colours, so a repeating glyph is probably the best
approach. NR probably isn't the best thing to use for an
international audience, but I'm sure someone could come up with a
pictographic symbol instead.

Robert.

 On 23/07/2014 23:52, Matthijs Melissen wrote:

 On 23 July 2014 23:16, Dan S danstowell+...@gmail.com wrote:

 Not really an issue for the tagging mailing list - I don't think the
 people who maintain the style are on here. If you're talking about the
 main osm.org style then it's openstreetmap-carto, maintained here:
 https://github.com/gravitystorm/openstreetmap-carto/

 More precisely for this issue:
 https://github.com/gravitystorm/openstreetmap-carto/issues/200
 https://github.com/gravitystorm/openstreetmap-carto/pull/491

 -- Matthijs


-- 
Robert Whittaker

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - bicycle=use_cycleway

2013-11-14 Thread Robert Whittaker (OSM lists)
On 14 November 2013 09:13, Martin Koppenhoefer dieterdre...@gmail.com wrote:
 I don't see why you can't tag the roads you're talking about
 with bicycle=no (or maybe something like bicycle=restricted for the
 cases where more significant use is allowed) and then add a second tag
 along the lines of bicycle:restriction=DE:use_cycleway to capture the
 fact that the legal exclusion of bikes is because of X country's
 parallel cycleway rules.

 You shouldn't do it, because it would be wrong. There is no legal exclusion 
 of bikes on the road, there is an obligation - under certain circumstances - 
 to use the cycleway, this is a difference and should not be tagged like an 
 exclusion of bikes on the road (e.g. like on a motorway)

Assuming that you meet the certain circumstances, I see little
practical difference between You can't cycle on the road and you
must use the cycleway and not the road in terms of whether or not you
are allowed to cycle along the road. Granted, crossing and turning may
be slightly different, but for general riding along a stretch of road
the effect will be the same -- you can't ride there.

However, these slight differences are why I suggested using
bicycle=restricted for when the prohibition caused by the presence of
a parallel cycleway isn't so absolute. Doing this would seem to be
perfectly correct -- cycling on the road is indeed restricted. Doing
it this way (rather than a single tag) has the advantage of using a
more general value on the access tag (that is thus more likely to be
interpreted in an appropriate fashion by more routers), while still
allowing (encouraging even) a more specific tag to capture the precise
detail of exactly what the (country-specific) restrictions are. We
then don't confuse the effect of the legal restrictions with the cause
of the restrictions. By encouraging mappers to specify the precise
source of the restrictions in a separate tag, we're less likely to get
mappers using a bicycle=use_cycleway style tag inappropriately due to
misunderstandings, and should end up with better-defined tags and more
accurate data.

-- 
Robert Whittaker

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - bicycle=use_cycleway

2013-11-13 Thread Robert Whittaker (OSM lists)
On 12 November 2013 18:16, Pee Wee piewi...@gmail.com wrote:
 Together with user Masimaster I've made a proposal for a new tag to improve
 bicycle routing. I think (and hope) the wiki is clear enough but I’ll say a
 few words about this new tag.

 The tag is introduced to separate 2 kinds of roads where you are not
 supposed to ride your bike.

I'm afraid I'm not convinced by the proposal at
https://wiki.openstreetmap.org/wiki/Bicycle_use_cycleway .

First of all, the proposal is not clear on exactly when this tag is to
be applied, in some places you say it's to be used when there is a
parallel compulsory cycleway, and elsewhere it says official. Then
use of allowed / wise also introduces ambiguity as to whether the
tag is intended only for routes where most cycling is banned on the
road, or just when cyclists would generally choose not to. This needs
to be clarified.

(In the UK for example, we often have cycle tracks running parallel to
the road. There is also an official government document called the
Highway Code, which includes the clause for cyclists: Use cycle
routes, advanced stop lines, cycle boxes and toucan crossings unless
at the time it is unsafe to do so. Use of these facilities is not
compulsory and will depend on your experience and skills, but they can
make your journey safer. It's not entirely clear from your proposal
whether or not the proposal means all UK roads with parallel cycle
routes should be tagged with bicycle=use_cycleway. I would presume
not, but I think the proposal as written is open to interpretation.)

Secondly, you mention the case of special types of bicycle eg
tricycles. I would argue that if such vehicles routinely have a
different legal status with respect to access rights in a particular
country, then they should be given a more specific access tag key to
over-ride any access tags set for bicycle. This is how we handle other
access issues where certain types of vehicle are an exception. (For
example, on a service road only open to buses and taxis, we would set
vehicle=no, psv=yes. Here we should use something like bicycle=no,
special-type-of-bicycle=yes.)

Finally, I think that it is not a good idea to introduce an access tag
value where the precise effect is going to vary by country and have
different meanings to different people. IMO the access tags should be
used to express absolute states as well as possible, rather than being
subject to different interpretations in different places. Routers etc
shouldn't need to know about different national laws and conventions
to interpret the main tag. (This is why, for example, we tag national
speed limits with a numerical maxspeed=* tag, and then provide a
supplementary maxspeed:type=* tag to explain how that numerical value
is derived. Or why in the UK, we tag access rights such as foot=yes in
addition to the legal origin of those rights e.g.
designation=public_footpath.)

So I would suggest that on any roads where cycling is generally
disallowed, we continue to use bicycle=no as the standard tagging. If
certain sub-types of bicycle are allowed, then an additional access
tag can be added to override bicycle=no for those cases. To express
the legal origin of the restriction, and provide the information to
routers that want it, I'd suggest adding tag along the lines of
bicycle:restriction_type=DE:use_cycleway where the value comes from a
country code and a table of values that list the various legal
statuses that may exist in each country. This has the advantages of
(a) using a backwards compatible bicycle=* value (b) allowing
users/routers that don’t want to be bothered with the details of
different restrictions to give a reasonable result that will be right
in most cases, (c) providing a standard way to record the precise
legal status of the route, (d) allowing routers that do want to be
bothered with the details to implement them on a country- and
law-specific basis. None of these advantages are present in the
original proposal.

If there are cases where it is less clear cut that cycling is
generally forbidden, then maybe a more generic tag of
bicycle=restricted might be better as the main tag, again in
conjunction with a separate tag to identify the precise restriction
that applies. (Yes this will mean the main bicycle=* tag needs to be
interpreted by routers, but at least it gives them a single generic
tag for you probably can't cycle here, but you need to check for
details which they can use to warn end-users if the router doesn't
want to work out the precise details themselves.)

Robert.

-- 
Robert Whittaker

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - bicycle=use_cycleway

2013-11-13 Thread Robert Whittaker (OSM lists)
On 13 November 2013 23:06, Matthijs Melissen i...@matthijsmelissen.nl wrote:
 In the Netherlands, segways, rollerblades, and skateboards are allowed
 on bike paths. In Austria, segways and rollerblades are allowed on
 bike paths, but skateboards are not. In Germany, segways are allowed
 on bike paths, but rollerblades and skateboards are not. Do we really
 want to tag every German path where there is a bicycle sign with
 segway=yes, rollerblade=no, skateboard=no? And possible a much longer
 list of vehicles that are treated as pedestrians under one legislation
 but as bikes somewhere else? Also, if the law changes, for example to
 include or exclude Segways, we would need to change all tags, even
 though nothing has changed on the ground.

 In the long run, I think it would be good if routers will be aware of
 the jurisdiction a road is in, and then derive the implications of a
 bike=no sign for other types of vehicles.

In which case,I don't think the already well-established access tags
are what you should be using for this. bicycle=no means you can't
ride a bicycle along here, not there's a no cycling sign that also
has other implications for different classes of user. If someone
(additionally or alternatively) wants to tag that a certain way has a
certain (most likely) country-specific status that implies certain
access restrictions on it, then it would be better to use different
tags for this. This way the ordinary access tags keep their usual
standard international meaning, and so can be used by routers etc that
are not aware of the specific rules. If people choose not to
explicitly tag segway=yes, that's fine, there will just be no explicit
information about segway use on that way. If there's a different tag
specifying that it's an official German Cycleway, then routers that
are aware of what that means can derive all the associated access
rights from that.

(In the UK, we use designation=* for certain special classes of public
right of way. Though many people will also add the associated access
tags that implies, presumably in part because most routers aren't
currently aware of how to interpret the designation tags.)

In short, I don't see why you can't tag the roads you're talking about
with bicycle=no (or maybe something like bicycle=restricted for the
cases where more significant use is allowed) and then add a second tag
along the lines of bicycle:restriction=DE:use_cycleway to capture the
fact that the legal exclusion of bikes is because of X country's
parallel cycleway rules. There's no need to add half-a-dozen extra
access tags if you don't want to. Routers that aren't aware of the
specific rules will get things right most of the time without needing
any adjustment. Routers that are aware of the rules will have a
specific tag to look for that allows them to apply the right rules for
that stretch of road. Not only is more information captured with this
scheme, if the legal implications of DE:use_cycleway change at any
point, there's a convenient key to use for any automated changing /
checking of the access tags that is desired.

Robert.

-- 
Robert Whittaker

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Usefulness of bicycle=dismount on ways

2013-10-15 Thread Robert Whittaker (OSM lists)
On 14 October 2013 16:35, Martin Koppenhoefer dieterdre...@gmail.com wrote:

 2013/10/14 Richard Mann richard.mann.westoxf...@gmail.com

 bicycle=no on the entry/exit node should suffice for routing

 +1, for routing that should be sufficient, but not for mapping ;-)
 If they are explicitly forbidden on all ways it would not be bad to have it
 on all ways as explicit tag (IMHO).

That rather depends on whether bicycle=no is interpreted to mean no
cycling or no bicycles -- which seems to be the key thing we need
to agree on first.

Robert.

-- 
Robert Whittaker

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Usefulness of bicycle=dismount on ways

2013-10-11 Thread Robert Whittaker (OSM lists)
On 10 October 2013 15:28, fly lowfligh...@googlemail.com wrote:
 +1 for a separate tag and deprecating  bicycle=dismount

To make the case for this clearer, consider the following. There are
four combinations of access for bicycles and cyclists, depending on
whether you are allowed to cycle and/or allowed to
push a bike:

(a) Cycling and pushing both allowed
(b) Cycling allowed, but pushing not allowed
(c) Cycling not allowed, but pushing is allowed
(d) Neither cycling nor pushing allowed

I beleive all of these combinations are possible in real life. In the
UK (a) would be a normal cycleway that's shared with pedestrians, (b)
could occur on a cycleway that's only for cyclists (i.e. no
pedestrians allowed), (c) would be the case of (e.g.) a narrow bridge
on a cycle route, where dismount signs are shown, or a typical
pedestrian shopping street with no cycling signs, and (d) would be
an area/route explicitly signed as e.g. no bicycles not even pushed
(Oxford University Parks used to be like this until a couple of years
ago).

Clearly if you are travelling with a bike you would want to
distinguish between at least (a)/(b) vs. (c) vs. (d), to determine
where you can go with your bike and at what pace.

Currently the tagging used is bicycle=yes/no/dismount. The problem
with this is that while bicyle=dismount unambiguously indicates (c),
people have used bicycle=no for both (c) and (d) -- interpreting it as
either no cycling or no bicycles. Also (although less importantly)
using bicycle=yes offers no way to explicitly distinguish between
cases (a) and (b).

I would therefore propose a new access tag be introduced to capture
information about whether pushing a bike is allowed. I'll call this
bicycle_pushed for now, but the actual name is something that can  be
discussed and agreed upon later.

With this tag and the existing bicycle=* access tag (whose values are
now taken, as I believe was originally intended, to apply to 'cycling'
rather than 'bicycles'), it is now possible to unambiguously
distingiush between the four cases above:

(a) bicycle=yes + bicycle_pushed=yes
(b) bicycle=yes + bicycle_pushed=no
(c) bicycle=no + bicycle_pushed=yes
(d) bicycle=no + bicycle_pushed=no

bicycle=dismount is then deprecated, and the same information captured
by using bicycle=no + bicycle_pushed=yes (i.e. no cycling, but you can
push your bike).

For actual tagging use, It might be worth considering that whether, in
the absense of a bicycle_pushed tag, the presense of foot=yes implies
you can push a bicycle on that route -- which is probably a sensible
default in most of the world. Although we would have to think
carefully about how to handle the case of people who have previously
tagged bicycle=no to indicate case (d).

Robert.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Usefulness of bicycle=dismount on ways

2013-10-09 Thread Robert Whittaker (OSM lists)
On 7 October 2013 17:09, fly lowfligh...@googlemail.com wrote:
 I wonder if it is useful to tag bicycle=dismount on ways.

 At least in Germany there is no official traffic sign despite of the
 existence of some.

I don't think the issue here is really whether there is a need within
instances of no cycling to distinguish between no bicycles at all
and bicycles can be pushed. It seems from the posts below that there
are plenty of situations where both cases apply, and it's clearly
important information to know if you're planning cycling routes. We
therefore do need a way to distinguish between the two cases.

The big problem that I see is (especially in areas where the default
position is no cycling = bikes can be pushed) that people have
used bicycle=no on ways where cycling is banned but it's fine to push
a bike. In other words the bicycle=* key has been used to express
access rights for cycling, not for bicycles. As a result (at least on
some areas) data users are forced to interpret bicycle=no as no
cycling, but bikes can be pushed as a best guess at what the mapper
meant. Thus bicycle=dismount actually add no further information,
except that you can be more certain that pushing bike is allowed.

If bicycle=* is currently widely used to express access rights for
cycling, then I'd suggest we leave it like that, as it does the job
pretty well. Rather than trying to add additional values to this key
to capture access rigths for pushed/wheeled bicycles (e.g.
bicycle=no_and_not_even_pushed), I'd suggest that we define an
additional key: Something along the lines of bicycle:pushed=*.
bicycle=* then tells you if you can ride a bike (as it does
currently), while bicycle:pushed=* tells you if you can push/wheel it.

Any cases of bicycle=dismount could be easily converted to bicycle=no,
bicycle:pushed=yes. The only issue is cases of bicycle=no which have
been used to mean no cycling and no pushing either. Perhaps it will
be necessary to look at national defaults to handle this (i.e. what
value of bicycle:pushed should be assumed if bicycle=no and there's no
bicycle:pushed=* tag present).

Robert.

-- 
Robert Whittaker

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Power tower and pole usefulness

2013-09-22 Thread Robert Whittaker (OSM lists)
On 22 September 2013 15:34, Martin Koppenhoefer dieterdre...@gmail.com wrote:
 I wouldn't tag them as man_made=tower

Me neither. The typical large metal framework structures for carrying
high-voltage electricity cables would be unlikely to be called towers
in normal British English language usage. I would guess that most
people would call them pylons. They also don't really fit with the
current OSM usage of man_made=tower, so if we have to use something
under man_made, I'd go for man_made=pylon.

 I wouldn't tag every antenna as tower neither, but of course there are 
 communication towers (e.g. there are some famous ones for tv).

I'd often use man_made=mast for tall single pole or lattice framework
structures.

Robert.

-- 
Robert Whittaker

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Proposal for new tag: landuse=plot

2013-09-18 Thread Robert Whittaker (OSM lists)
On 18 September 2013 18:44, Jonathan Bennett jonobenn...@gmail.com wrote:
 We already tag the whole site as landuse=allotments and we just need to
 mark individual plots with allotment[s]=plot(*). This makes it clear
 it's an allotment plot we're talking about, not anything else.

 Each plot will probably have a number (not necessarily a number) of
 some kind, and I'd suggest using ref=* for this.

 This appears to be about as complicated as it needs to get.

+1

 (*) Although natural spoken English would suggest tagging as
 allotment=plot, I can see how using allotments=plot makes it clear it's
 a sub-division of landuse=allotments, so I'd accept the plural form in
 the tag. But that's getting into Bikeshedding again.

I'd probably favour allotments=plot for the reasons given.

Robert.

-- 
Robert Whittaker

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging