Re: [Tagging] [OT] Licensing of information from websites

2015-03-31 Thread Dan S
2015-03-31 12:51 GMT+01:00 Andrew Guertin andrew.guer...@uvm.edu:
 I wonder that nobody so far did spell out a warning about adding
 information from websites. The simple key website=* is ok, but every
 information like address, prizes and all the amenities is most of the
 time not usable due to license problems.

 cu fly


 I'm pushing this offtopic and this discussion should probably go to
 legal-talk (I've set reply-to there), but that paragraph does not match my
 understanding of copyright law (IANAL, etc.).

 My understanding is that a piece of information like an address or phone
 number is a fact and is ineligible for copyright protection. If the fact has
 been collected into a database, though, the database is in some countries
 eligible for protection under a separate form of IP.

 Thus if you go to a business' website to find their phone number and put it
 in OSM, everything is okay, but if you go to a phone book to find it, that's
 not okay and you could impact use of OSM in jurisdictions that have database
 protections.

Andrew, you are correct. People who are concerned about licensing do
forget this distinction sometimes. You've described it very well (the
difference between copying a phone number and a phone book)

Best
Dan

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


Re: [Tagging] Loomio evaluation

2015-03-23 Thread Dan S
I don't know if I need to say this, but Ralph, Andre, please could you
send report your problems to the loomio people? You do that here:
https://github.com/loomio/loomio/issues

Dan

2015-03-23 16:42 GMT+00:00 AYTOUN RALPH ralph.ayt...@ntlworld.com:
 Well, I guess I am also out of this. Needs me to log in to make a comment
 but appears I have done something wrong because it just does not work for
 me. I do not have a Google account and my Virgin email is unacceptable.

 So I cannot comment.

 Question:... Can you include pictures or diagrams as visual arguments to
 support your reasoning?

 Cheers

 Ralph

 On 20 March 2015 at 22:38, Kotya Karapetyan kotya.li...@gmail.com wrote:

 Dear all,

 In an attempt to find a better tool for our proposal discussions, Loomio
 has been mentioned. At the very first glance it looks like a feasible
 alternative to the mailing list and the forum.

 Let's take a look together: https://www.loomio.org/g/tknueHrw/osm-tagging

 And let me know if you want to check the coordinator role.

 Cheers,
 Kotya

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



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


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


Re: [Tagging] Loomio evaluation

2015-03-23 Thread Dan S
OSM is a very large community with much accumulated knowledge and
skill - it's bound to be quite conservative, and for good reason. The
challenge is to allow experimental innovations to breathe without
disrupting the community. We'll never be able to organise a vote (ha!)
to switch to loomio all at once. But if we decide Loomio is worth
trying, maybe we can experimentally agree to use it to negotiate some
small tagging subproject, in a particular tag namespace. (indoor
tagging might be a good example?) Then inch by inch we see what works.

Dan


2015-03-23 0:18 GMT+00:00 Dave Swarthout daveswarth...@gmail.com:
 I'll second the notion that we need something better than the current
 system. It is an anachronism!

 My first look at Loomio was good, I was impressed, but my immediate thought
 was, it'll never get accepted into OSM

 On Mon, Mar 23, 2015 at 5:57 AM, Dan S danstowell+...@gmail.com wrote:

 It's interesting. I hadn't realised it's open-source too, so osm could
 run its own version of it if we wanted to.

 Dan

 2015-03-20 22:38 GMT+00:00 Kotya Karapetyan kotya.li...@gmail.com:
  Dear all,
 
  In an attempt to find a better tool for our proposal discussions, Loomio
  has
  been mentioned. At the very first glance it looks like a feasible
  alternative to the mailing list and the forum.
 
  Let's take a look together:
  https://www.loomio.org/g/tknueHrw/osm-tagging
 
  And let me know if you want to check the coordinator role.
 
  Cheers,
  Kotya
 
  ___
  Tagging mailing list
  Tagging@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/tagging
 

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




 --
 Dave Swarthout
 Homer, Alaska
 Chiang Mai, Thailand
 Travel Blog at http://dswarthout.blogspot.com

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


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


Re: [Tagging] Loomio evaluation

2015-03-23 Thread Dan S
Yes they can. Probably best to try it out - sorry that you're stuck
outside of it at the moment!

2015-03-23 18:36 GMT+00:00 AYTOUN RALPH ralph.ayt...@ntlworld.com:
 The next question is

 The results of the graph are based on the response of the person when they
 post their comment. This affects the result of the pie chart because it
 starts to clock up how people feel before all the comments for and against
 have been posted. Those later arguments could affect the earlier decisions
 and change people's minds. Can they retract their earlier position and
 change or reverse their input to the pie graph?

 On 20 March 2015 at 22:38, Kotya Karapetyan kotya.li...@gmail.com wrote:

 Dear all,

 In an attempt to find a better tool for our proposal discussions, Loomio
 has been mentioned. At the very first glance it looks like a feasible
 alternative to the mailing list and the forum.

 Let's take a look together: https://www.loomio.org/g/tknueHrw/osm-tagging

 And let me know if you want to check the coordinator role.

 Cheers,
 Kotya

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



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


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


Re: [Tagging] Loomio evaluation

2015-03-22 Thread Dan S
It's interesting. I hadn't realised it's open-source too, so osm could
run its own version of it if we wanted to.

Dan

2015-03-20 22:38 GMT+00:00 Kotya Karapetyan kotya.li...@gmail.com:
 Dear all,

 In an attempt to find a better tool for our proposal discussions, Loomio has
 been mentioned. At the very first glance it looks like a feasible
 alternative to the mailing list and the forum.

 Let's take a look together: https://www.loomio.org/g/tknueHrw/osm-tagging

 And let me know if you want to check the coordinator role.

 Cheers,
 Kotya

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


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


Re: [Tagging] List v Forum - was Accepted or rejected?

2015-03-20 Thread Dan S
2015-03-19 22:42 GMT+00:00 Kotya Karapetyan kotya.li...@gmail.com:
 On Thu, Mar 19, 2015 at 11:28 PM, Dan S danstowell+...@gmail.com wrote:

 I use Stack Exchange a lot and it's great, very well designed for its
 purpose. BUT Stack Exchange is not designed for community decision
 making. There are tools/forums that are actually designed for that
 purpose.

 Also I don't think Stack Exchange themselves would want to host an OSM
 tagging area, it's not what they're about. Maybe someone has in mind a
 stack-exchange-like system rather than Stack Exchange itself. In fact
 https://help.openstreetmap.org/ uses http://www.osqa.net/ which is
 a Stack Exchange clone. But I repeat, it's not designed for
 consensus/decision-making, it's designed for QA, which has
 superficial similarities (voting etc) but it's not the same thing.


 Dan, all true.
 1) Can you point in the direction of the tools you mean (designed for that
 purpose)? Do you know a good one?

I'm sorry, there was one recommended in a recent HOT email, but there
have been so many HOT and OSM emails recently that I can't find which
one was recommended :/

 2) I know that SE as not designed for lengthy discussions. (It provides the
 meta and chat though.) I was thinking more in the direction of proposing a
 tag like a question. Then people can edit/comment/vote. It's a very
 different approach, but I am not sure we need the current one with so much
 text and noise.
 3) My main point was actually not to say that SE is the best solution, but
 to emphasize to the forum proponents that forums are far from ideal too.

 Cheers,
 Kotya

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


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


Re: [Tagging] List v Forum - was Accepted or rejected?

2015-03-20 Thread Dan S
2015-03-20 11:50 GMT+00:00 althio althio.fo...@gmail.com:

  I use Stack Exchange a lot and it's great, very well designed for its
  purpose. BUT Stack Exchange is not designed for community decision
  making. There are tools/forums that are actually designed for that
  purpose.

  1) Can you point in the direction of the tools you mean (designed for
  that
  purpose)? Do you know a good one?

 I'm sorry, there was one recommended in a recent HOT email, but there
 have been so many HOT and OSM emails recently that I can't find which
 one was recommended :/

 Maybe it was Loomio?

That was it! Thanks

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


Re: [Tagging] Revisiting proposal/voting scheme

2015-03-19 Thread Dan S
2015-03-18 23:56 GMT+00:00 David Bannon dban...@internode.on.net:
 Kotya, in no way was I criticising the leadership you have shown in this
 matter !

 Its just that I preferred Dan's approach. Key IMHO is -

 * A proposal gets to wiki in much the same manner as now.

 * Once on the wiki, instead of a formal vote period, users (eg) click a
 like or dislike button and aggregate score is shown. For some time
 (?). Obviously they can also edit content to say why.

 Now, we don't have that content freeze when voting formally starts. Is
 it a problem that I click 'like' and some important change is made to
 content later ?

Yes it's a problem, but I hope that's small enough to ignore, because
people can delete or switch their votes whenever they like. I guess in
the very very first stages, when someone writes something flawed, we
might want a don't vote yet stage (as we do now) so that a page
doesn't accumulate lots of {{no}} of which at least some of them won't
bother revisiting their opinion.

Dan


 David

 On Wed, 2015-03-18 at 23:57 +0100, Kotya Karapetyan wrote:


 Ahhm, not sure how it is different, but never mind. I will be happy if
 we all agree on a good solution, and I definitely don't claim the
 authorship of all the good ideas that have popped up here over the
 last couple of days. I just tried to summarize it in something that
 looked to me like a working solution. Dan, thanks for making a good
 illustration :)

 Quite a good one really. It meets my
 criteria  of giving a new mapper some guidance on what he/she
 should
 use.



 Good to hear :)

 Add in taginfo data.


 Yes: Opinions for and against are expressed in the discussions
 and summarized at the top of the page (e.g. advantages and
 disadvantages of a tag) together with the current usage


 And maybe a list of competing approaches so, again, its clear
 to a new
 user what the options are.


 It clearly belongs a see also section IMO.





 I do think we'd need to have some (usage determined ?) end
 point
 however. Who is going to register their approval of, eg,
 highway= this
 far down the track ?

 I think data consumers also need a bit of certainty too.


 End of what?

 Usage, as discussed in another thread, is a vague criterion. Two tags
 may have a full support of the community, one having thousands of uses
 and another (for a rare feature) ten.
 For data consumers---definitely yes, and I suggest it being the moment
 when we remove the proposal status, so the page becomes a feature
 page. The moment can be when the discussion calms down (which can
 even be defined mathematically if needed).


 Sorry guys, no more spamming today :) Hopefully we'll converge to
 something good, so these discussions won't be in vain :)


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



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

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


Re: [Tagging] Revisiting proposal/voting scheme

2015-03-18 Thread Dan S
2015-03-18 21:58 GMT+00:00 David Bannon dban...@internode.on.net:
 On Wed, 2015-03-18 at 21:40 +0100, Kotya Karapetyan wrote:

  . would it make sense to change the current proposal/voting
 mechanism like follows?
 
 - When the discussion calms down (which can even be defined
 mathematically if needed), this very page is converted into a feature
 page. It is never approved or rejected, but the opinions are made
 clear.

 No, I'm sorry but I don't see how an interested party can be expected to
 objectively determine what the discussion concluded.  If we absolutely
 must measure data in the database, how can we do otherwise in our
 processes ?

 About the only way would be to count up the emails for/against. And then
 discount the early ones as they would apply to early drafts of the
 proposal. Try and allow for the fence sitters

 No, sorry, but a vote and an outcome may offend some politically correct
 members but it is necessary.

It has nothing to do with politically correct - what a curious idea!
It's about designing the mechanism so that it does what we want it to
do. Lots of people repeatedly say that it doesn't. We don't all agree
what's broken about it...

I like the general approach Kotya proposes. It seems correct that we
want to keep the positive aspects of voting (discussion, refinement,
in one focal place, with some straw poll of community acceptance)
but the biggest issue people seem concerned about here is that
converting that straw poll into a blunt approved/rejected is not
helpful because it conflates some very different situations.

So here's how I would answer your question of how would an interested
party [...] objectively determine what the discussion concluded:
instead of approved/rejected, some sort of visual widget on the wiki
page which summarised the {{yes}} and {{no}} with something like 76%
support [out of 98 opinions]. The poll would give a quick guide to
mappers, and encourage others to chip in with their opinion - any user
could add or remove their {{yes}}/{{no}} at any point.

Dan

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


Re: [Tagging] Accepted or rejected?

2015-03-14 Thread Dan S
Hi,

No, I think it means what it says. Or at least, I think we have
treated it that way for a long while.

When there is very low interest (i.e. very few votes) - which is
pretty common - then even one dissenting vote is enough to make us
step back and think again, whereas if there are enough votes to make
majority approval a meaningful concept (I admit that 15 is a low
number for quorum) then we accept that there will always be some
disagreement, and so we use majority rather than unanimity.

This is how I interpret it. I'm not saying it's the best rule of thumb
out there. I'd say there's no point changing it in small ways - no-one
likes the tag voting system, and overhaul would be better than slight
tweaks.

Anyway, it is only a rule of thumb!

Best
Dan


2015-03-14 11:24 GMT+00:00 Jan van Bekkum jan.vanbek...@gmail.com:
 The guideline to determine if a proposal is accepted is

 A rule of thumb for enough support is 8 unanimous approval votes or 15
 total votes with a majority approval, but other factors may also be
 considered (such as whether a feature is already in use).

 This sounds a bit strange to me: a proposal with 8 approval votes and 1
 decline would be rejected, while one with 8 approval votes and 7 declines
 would be accepted.

 I suppose that this is what was intended:

 enough support is 8 approval votes on a total of 14 votes or less and a
 majority approval otherwise.

 Regards,

 Jan

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


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


Re: [Tagging] Buildings blocks

2015-03-12 Thread Dan S
2015-03-11 12:06 GMT+00:00 Martin Koppenhoefer dieterdre...@gmail.com:

 2015-03-11 12:56 GMT+01:00 Jean-Marc Liotier j...@liotier.org:

 As you can see, each block is subdivided into land plots - each with a
 courtyard and several buildings that usually all belong to an extended
 family. Those land plots have a strong significance and the frequent
 sighting of spontaneous attempts by to map them in various ways is testimony
 to that.

 I do not yet have an answer to this requirement - it should obviously be
 mapped as an area but I have so far failed to select satisfactory attributes
 to model it. I believe that landuse=* is not suitable - in Senegal, as
 http://wiki.openstreetmap.org/wiki/FR:WikiProject_Senegal recommends, the
 whole urban area is landuse=residential, so it is not available to map
 smaller subdivisions.




 maybe a new place value? Of the existing ones, maybe place=neighbourhood?
 Although this is a really small nieghbourhood compared to other areas with
 this tag.

 I don't see a problem in the whole area being landuse=residential, still you
 could split these into several smaller landuse=residential, but I agree that
 there will be no inherent semantics about the special situation there with
 just the landuse tag.

I also think that landuse=residential, plus name=* or whatever, is
fine. It's how I and some others map housing estates in the UK. I
might carve out a portion of the larger landuse=residential. (Not
everyone does it this way.)

Dan

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


Re: [Tagging] Blatant tagging for the renderer: bridges abandoned railways

2015-03-09 Thread Dan S
2015-03-09 16:18 GMT+00:00 ael law_ence@ntlworld.com:
 The edits you did can be described as (semi-)vandalism.

 That sort of comment is unworthy of OSM. I did the surveys. Very
 carefully. I tagged corectly as far as I knew at the time.
[...]
 Your sort of comment to someone who has contributed years of solid work
 to OSM is enough to make me consider ceasing to contribute.

On behalf of other people, I'd like to apologise for that comment.
People on this list, and elsewhere, seem to have  using the word
vandalism to describe various types of edit that disagree with their
perception of OSM consensus, rather than the true meaning of
vandalism which I don't need to spell out here. That's a lazy habit
and very rude to the recipient.

Best wishes
Dan

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


Re: [Tagging] ?=maze

2015-02-19 Thread Dan S
Yes Mateusz, +1 from me, sounds good -
Dan

2015-02-19 8:00 GMT+00:00 Mateusz Konieczny matkoni...@gmail.com:
 I think that attraction=maze is better than attraction:type (shorter,
 without colon, type is not
 really adding anything useful, clear detailing of tourism=attraction).

 2015-02-19 3:59 GMT+01:00 Bryce Nesbitt bry...@obviously.com:

 If it's of interest to outsiders it seems like an attraction.  Thus how
 about:


 tourism=attraction
 attraction:type=maze
 name=Happy Tunnel Kiddie Maze
 website=http://maze.example.org/


 You want all those similar features (maze/tube hill/ride/garden/water
 park/whatever) to show up on a tourism/visitor type map.
 This is also a clear case where the existing maze tags could be mass
 retagged to the new scheme.

 ---
 You just want to be clear if a given feature is PART of a larger
 attraction (e.g.
 one ride in a water park), or if it's the high level feature (e.g. the
 water park itself).
 See also http://wiki.openstreetmap.org/wiki/Tag:tourism%3Dtheme_park
 and the associated tagging.

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



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


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


Re: [Tagging] building=yes on nodes?

2015-02-16 Thread Dan S
All building=* on nodes is fine. As others have pointed out, it is
often necessary in HOT aerial mapping when we have low-resolution
imagery to work from.

Also, for humanitarian purposes there are serious uses for node-only
buildings, for estimating the population or the population
distribution in a place.

I've edited the wiki to set onNode=yes. I hope that doesn't lead to a storm

Best
Dan

2015-02-16 18:10 GMT+00:00 Lukas Sommer sommer...@gmail.com:
 I would like to return to the original question:

 1.) I think it is confusing to have building=cowshed allowed on nodes,
 but building=cabin not allowed. We should unify this. Either _all_
 building=* keys can be used on nodes, or _none_.

 2.) If we agree on 1.), would we opt to allow nodes or to disallow
 nodes? After reading the previous comments, I would tend to allow it.

 Best regards

 Lukas

 2015-02-16 12:12 GMT, fly lowfligh...@googlemail.com:
 Am 14.02.2015 um 23:06 schrieb Tobias Knerr:
 On 14.02.2015 22:11, SomeoneElse wrote:
 ... it also says that it shouldn't be used on relations, which would
 exclude perfectly valid multipolygons, such as this one:

 Multipolygons are a means to map areas. So they are covered by the area
 icon.

 The relation icon stands for relations that are not areas,
 just as the way icon stands for ways that are not areas.

 How about type=building ?

 It appears that again people are trying to use the wiki to tell other
 people how to map rather than describe how things tend to be mapped.

 Nobody is telling anyone not to use multipolygons.

 This is totally misleading as the type of the object is still a
 relation. Once we introduce an area object we might cover closed ways
 and multipolygones as one category. For now we depend on the object type
 or e.g. editor software already need to implement the area type to offer
 proper presets.

 cu fly

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



 --
 Lukas Sommer

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

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


Re: [Tagging] Feature Proposal - RFC - Reception Desk

2015-02-06 Thread Dan S
Hi,

No big objections from me, sounds useful.

However it occurs to me that it would be useful to have some way of
indicating _what_ it is the reception for. For example, if it was part
of a site relation*, then a role like role=reception would connect
it to the larger entity in a meaningful way. That might be a suggested
tagging option...

Best
Dan


* http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site



2015-02-06 2:03 GMT+00:00 Warin 61sundow...@gmail.com:
 Hi,

 Request for comment on new tag 'amenity=reception_desk'

 https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dreception_desk

 This comes out of the tag ON HT E tourism=camp_site WIKI PAGE which has a
 sub key of camp_site=reception.

 As 'Receptions' are numerous outside of camp sites I think it is best to
 have them available for use under other things - like hotels. So the new
 tag.

 'reception_desk' .. should separate it from other types of receivers .. like
 radio receivers.

 Amenity is the best fit so amenity=reception_desk.

 what do you think?





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

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


Re: [Tagging] Ethnic shops

2015-01-28 Thread Dan S
2015-01-28 18:52 GMT+00:00 Eric SIBERT courr...@eric.sibert.fr:
 I started modifying the wiki following our recent discussion.

 For cuisine=*, I added:
 May also apply to other services that deliver food, like convenience.

 For shop=convenience, I added (in Tags used in combination):
 Stores selling specific type of food or with ethnic origin may use
 {{tag|cuisine}} to indicate it.


 And latter go on with culture=* for nonfood services?

Hi - my 2p: yes sounds fine. I agree with others who said that
culture=* seems a decent choice (since more flexible and less awkward
than ethnicity=*)

Best
Dan

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


Re: [Tagging] Deprecation of associatedStreet-relations

2015-01-22 Thread Dan S
2015-01-22 6:53 GMT+00:00 Marc Gemis marc.ge...@gmail.com:
 It seems like the German community started some voting process on the
 deprecation of the associatedStreet-relation (it was on the mailing list and
 on the forum).

 Discussion is going on on the wiki
 https://wiki.openstreetmap.org/wiki/DE:Relation:associatedStreet

Hi all - does anyone know what the geographic distribution of
associatedStreet is like? taginfo doesn't render a map (it seems it
doesn't do that for relations). I hear rumours it's mainly Germany but
it'd be handy to know.

Best
Dan

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


Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

2015-01-21 Thread Dan S
Now you're insulting the one person who was supporting you? Please
STOP this thread everyone. Please.

2015-01-21 8:55 GMT+00:00 Никита acr...@gmail.com:
 Just because one can use a regular expression to grep out a certain
 meaning doesn't mean it's a good thing to do and will always work
 We easily revert these edits in Russia. Quite often user who want to show
 their regex fu will fail so hard to guess actual properly of the real world.

 We care about data we map.
 We document it instead of guessing by taginfo.
 We use real tags instead of regexes for users.

 We like our newbies. We don't want to insist to use f$#$g perl regexes
 simply to map things around them.

 I cannot stop you from using regex. But if I find your changsets erroneous I
 will revert them.

 In fact, nobody forces us to only use yes and no as a value.
 Wrong. It not forces you anything. You can still tag currency:X=fixme.

 The Healthcare 2.0 proposal uses partial, main, yes and no. This can
 easily applied to a lot of values where it makes sense and it gives the
 flexibility to distinguish between equal and distinguished importance .
 There way more tagging schemes than single Healthcare 2.0. Yes there
 differences, so what?

 Using semicolon-lists for values was always considered a crutch until a
 better tagging-scheme comes along.
 You forgot to say among English speaking users who fail to use JOSM search
 funtion or overpass or taginfo or wiki documentation. I don't care about
 them.

 We all know that the only real solution would be a native data type for
 arrays in the database but as long as this isn't happening, we have to work
 around.
 And obviously you choose the worst way to do this. With complicating things
 with REGEX.


 2015-01-21 11:42 GMT+03:00 Nadjita tagg...@mark.reidel.info:

 On 21.01.2015 09:06, Никита wrote:

  If you trying to parse name=school *with any regex *to map it as
  amenity=school* *you are wrong. OSM is not for you.
  If you trying to parse currency=bitcoin;coin for coin, then stop it
  right now. You have no idea how regexes or tags in osm work.

 While I think, you should really calm down a bit and not sound so
 aggressive, I have to agree with you. The purpose of structuring data is
 not having to use a complicated, but a simple parser. Just because one
 can use a regular expression to grep out a certain meaning doesn't mean
 it's a good thing to do and will always work.
 The only downside of currency:X=yes, currency:Y=yes to currency=X;Y is
 that it involves more typing. In fact, nobody forces us to only use yes
 and no as a value. The Healthcare 2.0 proposal uses partial, main, yes
 and no. This can easily applied to a lot of values where it makes sense
 and it gives the flexibility to distinguish between equal and
 distinguished importance .
 Using semicolon-lists for values was always considered a crutch until a
 better tagging-scheme comes along.
 We all know that the only real solution would be a native data type for
 arrays in the database but as long as this isn't happening, we have to
 work around.
 But please let's not drag this down to a personal level and start
 insulting each other, this isn't going to accomplish anything but anger.

 - Nadjita

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



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


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


Re: [Tagging] Feature Proposal - RFC - addrN:*

2015-01-16 Thread Dan S
2015-01-15 23:48 GMT+00:00 Friedrich Volkmann b...@volki.at:
 On 15.01.2015 13:10, Dan S wrote:
 The addrN scheme is really quite awkward

 Can you explain why you find it awkward?

 It seems to me that the displeasure felt with the addrN scheme is caused by
 a phenomenon called transference. Multiple addresses in the real world are
 awkward, but they do exist and we cannot change that annoying fact.
 Therefore, the negative feeling transfers to the tagging scheme that
 represents the awkward reality. The awkward reality cannot be defeatet, but
 its representation can.

I would give a different reason: I find it awkward because OSM's data
model, with a flat list of key=value tags, doesn't fit well to this
particular reality. A lovely data model would be hierarchical, where
our object could have an addr key containing two values, and those
two values would themselves each be a dictionary of housenumber=Y
street=X ... etc. That's why I find it awkward - but as I said, in my
opinion there isn't a non-awkward way to solve this!

Dan

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


Re: [Tagging] Ethnic shops

2015-01-16 Thread Dan S
That's not a flaw - you've already given the solution in your own email:

 Basically you want to label restaurants/shops only if they offer something
 different from what's the typical local fare.




2015-01-16 13:23 GMT+00:00 Volker Schmidt vosc...@gmail.com:
 This, and already the existing tagging for restaurant cuisine have a basic
 flaw. They only work in a few countries of the West.
 If you think about it, most likely al restaurants in China would have to
 have cuisine=chinese, or all grocery stores in Marocco would have to be
 labelled convenience=north_african or whatever.
 Basically you want to label restaurants/shops only if they offer something
 different from what's the typical local fare.

 I have no proposal, I am just observing.



 On 16 January 2015 at 13:45, Martin Koppenhoefer dieterdre...@gmail.com
 wrote:


 2015-01-16 13:29 GMT+01:00 moltonel 3x Combo molto...@gmail.com:

 I've recently tagged a shop=convenience, convenience=polish. You'll
 find a handfull of other examples of convenience=* clothes=*
 hairdresser=* on taginfo.



 I suggest to use a more specific key that already tells in its name what
 it is about, and that allows for tagging several orthogonal properties. The
 current values for convenience (in total only used 11 times) are:
 http://taginfo.openstreetmap.org/keys/convenience#values

 yes
 russian
 mall
 pet
 polish
 variety_store
 african
 wine;honey;rice;pastery;book

 so basically there is no system, and the values make it hard if not
 impossible to understand what is actually tagged.

 I have found these in taginfo:

 ethnicity (total use 65)
 http://taginfo.openstreetmap.org/keys/ethnicity

 origin (used more often, but has the same problem then convenience, it
 is mixed up with different concepts)
 http://taginfo.openstreetmap.org/keys/origin#values

 cheers,
 Martin

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



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


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


Re: [Tagging] Feature Proposal - RFC - addrN:*

2015-01-15 Thread Dan S
2015-01-15 11:53 GMT+00:00 Martin Koppenhoefer dieterdre...@gmail.com:

 2015-01-15 12:43 GMT+01:00 Janko Mihelić jan...@gmail.com:

 With addrN:*=* it's clear that the same place has two addresses. If there
 are two nodes, it seems like there are two places (Two entrances, two
 apartments, two rooms), each with it's own address. AddrN* is clearly
 superior in this aspect.

 you could use polygons (e.g. 2 distinct multipolygons, one for each
 address), and add a note to inform your fellow mapping colleagues that the
 overlap is intended (note is not needed but nice).

I was thinking about this solution too. The addrN scheme is really
quite awkward so it'd be nice to recommend something like simply
having two nodes/multipolygons with exactly the same overlapping
geometry. However, this gets horrible too: if both of the addresses
refer to a pub, should both objects be amenity=pub? (No!) Should they
be grouped under a relation which holds amenity=pub other properties?
Maybe, but that's getting just as awkward as addrN... It looks like
there's a problem to be solved, and none of the solutions is pleasant.
Hence I abstain ;)

Best
Dan

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


Re: [Tagging] [OSM-talk] Changeset messaging Notes feature question

2015-01-09 Thread Dan S
This appears to be nothing to do with tagging - you've presumably
sent to this list by mistake...

2015-01-09 12:12 GMT+00:00 Dave F. dave...@madasafish.com:
 On 01/01/2015 00:39, Tom Hughes wrote:

 On 01/01/15 00:36, Dave F. wrote:

 I'm struggling to comprehend how a button to turn off the notes layer,
 that's separate ( hidden!) from the only obvious button to turn the
 layer on can be described as 'logical' to an experienced user let alone
 a newbie..


 Well the problem is that what you see as a button to turn on the notes
 layer is what I see as a button to add a new note ;-) That button was
 intended to encode the add a note action, not the view notes action.


 OK, but however you perceive it, it still activates the 'view notes'.
 Although it adds clarity to do so, it's not essential to the 'add a note'
 function.

 If I just wanted to view existing notes I wouldn't use that button, I
 would open the layer switcher and turn on the notes layer.


 On a scale of 1 to 10, how obvious do you think that is to the user?



 The problem with turning off the notes layer again when the add note
 control is disabled is that it might already have been on before you
 started adding a note, so we would probably have to remember if we had
 turned it on or if it was already on .


 Trying to figure out what to do if somebody starts toggling the notes
 layers on and off manually while the add note control is active just
 introduces even more levels of complication...


 By 'we' do you mean the programmers? I hope not. It's not that
 complicated! on/off, yes/no, 0/1 binary! It's the DNA of computers!


 No I'm not saying the programming is necessary complicated, I'm saying
 it's hard to know what the correct behaviour is from a UX point of view.


 I don't really see it as that confusing:

 I don't think the 'add note' button needs to turn on the 'view notes', but
 lets assume it does:

 * The 'add note' button turns both the add  view layers on  should them
 off again, except if 'view' was previously turned on via hidden option under
 Layers. Then it should leave 'view' on.

 * If 'view' is turned off via the Layers menu while 'add' is visible, turn
 'view' off as it not directly linked or strictly needed to add a note.

 Cheers
 Dave F.

 ---
 This email has been checked for viruses by Avast antivirus software.
 http://www.avast.com


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

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


Re: [Tagging] pre-RFC: relation type=cluster/group

2015-01-06 Thread Dan S
Hi -

Does relation=site help? It sounds to me like a very similar concept:
http://wiki.openstreetmap.org/wiki/Site

Best
Dan

2015-01-06 10:36 GMT+00:00 Friedrich Volkmann b...@volki.at:
 I was going to write a proposal for relation type=cluster
 (http://wiki.openstreetmap.org/wiki/Relations/Proposed/Cluster). Looking for
 real-world examples, I noticed that there's a relation type=group for the
 Great Lakes (id=1124369).

 What do you like better? type=group or type=cluster?

 --
 Friedrich K. Volkmann   http://www.volki.at/
 Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

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


Re: [Tagging] pre-RFC: relation type=cluster/group

2015-01-06 Thread Dan S
Oh, sorry, I see you mention it in the proposal. Still I don't see
what would be bad about using site for the examples in your
proposal, but I'll leave that there since you presumably feel
differently.

Dan

2015-01-06 10:18 GMT+00:00 Dan S danstowell+...@gmail.com:
 Hi -

 Does relation=site help? It sounds to me like a very similar concept:
 http://wiki.openstreetmap.org/wiki/Site

 Best
 Dan

 2015-01-06 10:36 GMT+00:00 Friedrich Volkmann b...@volki.at:
 I was going to write a proposal for relation type=cluster
 (http://wiki.openstreetmap.org/wiki/Relations/Proposed/Cluster). Looking for
 real-world examples, I noticed that there's a relation type=group for the
 Great Lakes (id=1124369).

 What do you like better? type=group or type=cluster?

 --
 Friedrich K. Volkmann   http://www.volki.at/
 Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

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


Re: [Tagging] Mapping of kids areas

2014-12-15 Thread Dan S
Hi,

The obvious question is: why not using leisure=playground? Since the
definition in the first link you give says an area where kids can
play.

Dan

2014-12-15 10:51 GMT+00:00 Dmitry Kiselev dkise...@osm.me:
 Hi

 We have
 http://wiki.openstreetmap.org/wiki/Amenity_features#kids_area.3Dno.2Findoor.2Foutdoor.2Fboth
 for kids areas mappings.

 But sometimes kids area is an independant amenity. I think it would be nice
 to have amenity to map such features.

 So here is mine proposal for that
 http://wiki.openstreetmap.org/wiki/Kids_area

 Looking forward for any comments and suggestions.

 --
 dkiselev
 Dmitry Kiselev

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


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


Re: [Tagging] Combining gas stations convenience stores

2014-12-05 Thread Dan S
Hi -

It doesn't make sense to me to have a specific tag for fuel and
convenience. Maybe I misunderstand you. I would say, keep copying the
addresses! There are lots of situations where multiple co-located
items have the same address, e.g. a small post office inside a
supermarket. If you invented a new tag it would be harder for people
to find the convenience shop...

Best
Dan


2014-12-05 5:19 GMT+00:00 Hans De Kryger hans.dekryge...@gmail.com:
 Hopefully this gets enough attention on the tagging list. Thought about
 posting this to talk U.S but changed my mind.

 Anyways to my problem. One of my passions to map in osm is gas stations.
 I've done hundreds since I've joined and now have fully come to realize a
 persistent problem that occurs frequently. The duplicate address tagging of
 a gas station and convenience store run by the same company. For example,
 say i just added a circle k gas station down the street from me to osm. But
 the gas station also has a convenience store. Well i have to copy over all
 the address info from one poi to the other since leaving the address Field
 blank makes no sense if someone would like to get there using a navigation
 app. I have thought about it a lot. And i go back and forth thinking both
 places should be tagged. Still a part of me thinks it makes no sense to have
 a address for a gas station tagged twice. One reason we cant completely
 combine the gas station and convenience store tag is some gas stations have
 the convenience store run by separate companies. As is the case with a
 circle k down the street from me. The convenience store is a circle k but
 the gas station is a shell. It would be nice to have a separate tag that
 combined the gas and convenience store shop together. I just want to make
 clear i don't want to get rid of the existing tags i just want to add one.

 Regards,

 Hans


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


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


Re: [Tagging] path vs footway

2014-11-04 Thread Dan S
One of the most important differences is that for highway=footway, we
know that pedestrians are allowed (unless other tags alter the access
explicitly). With highway=path we can't always assume that pedestrians
are allowed along it. I know there are routing systems that care about
this difference.

As others have said, the choice of which to use is very very fuzzy,
but if you use highway=path please make sure to use some access
tagging to say what kind of traffic may pass along it.

Best
Dan


2014-11-03 22:38 GMT+00:00 Mike Thompson miketh...@gmail.com:
 I am editing trails in a US National Park of which I have first hand
 knowledge.  Nearly all trails in this area have been tagged
 highway=footway although most of them are open equally to foot
 traffic and horse traffic. Any reason to leave them as footways? The
 wiki suggests that path is more appropriate. It would be nice to
 have consistent data, otherwise it suggests that one trail is
 different from the next when if fact they are not.

 By the way, might this be an artifact of the defaults in Potlatch?

 Thanks,

 Mike

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

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


Re: [Tagging] Pathways with steep vertical slopes, accessed via climbing chains

2014-11-04 Thread Dan S
Hi -

I don't have a direct answer I'm afraid. But please try not to think
about what gets rendered - the default style shown on the osm.org
homepage is just one of hundreds of rendering styles that are used. If
there are existing tags in use, great, whether or not they show on the
osm.org rendering. If not, then maybe you and others can think of
tagging that represents things properly - get the semantics right,
leave the rendering to the renderers.

Best
Dan


2014-11-04 3:28 GMT+00:00 johnw jo...@mac.com:
 Went hiking on mt Miyogi yesterday in Gunma, and like other steep mountain
 parks, sections of the trail were near vertical or completely vertical
 sections of trail that have to be climbed by chains and occasional
 footholds.  the longest was over 30m. the shortest was about 4m.

 http://www.openstreetmap.org/#map=16/36.2861/138.7454

 http://www.gunmajet.net/wp-content/uploads/2013/07/photo_02-copy.jpg
 someone posted up the route they took, and the hiking maps show the easier
 trail in blue (his yellow route, it goes over a section of chain.) and the
 dangerous ones in red.
 Chains area also used to show access to features near the trail via chain
 assisted climbing

 The current tail map needs to be expanded, and I want to work on that. but
 I’m wondering how to visually show that chains are necessary. I know other
 trails in other countries have similar permanent guide fixtures (cables,
 ropes, ladders in the rock,) where normal hikers are expected to use them.

 now, you might think that this is considered climbing, and you’d have a
 helmet, but people were scampering up the rocks, old guys and 10 year olds
 alike.  These “blue” sections were considered passable by regular hikers,
 and the upper level sections of the mountain were all marked for
 professional climbers (“red” routes with the red 危 splat) because a slip off
 the trail or the chain would mean death (200m drops).

 is there some method to tagging these that is rendered (that’s not steps) to
 visually show that chains or other assist devices are used?

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


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


Re: [Tagging] Default maxspeed unit on waterways

2014-10-29 Thread Dan S
2014-10-29 14:07 GMT+00:00 Pieren pier...@gmail.com:
 On Wed, Oct 29, 2014 at 2:52 PM, Tom Pfeifer t.pfei...@computer.org wrote:
 km/h is derived, at least with an integer multiple of seconds,
 from SI units. mph and knots are not. I would prefer to keep
 one default unit per tag, consistently, everything else leads
 to confusion.

 What is leading to confusion is to suggest that km/h is the default
 unit for waterway speed when  knot is in use everywhere.

Pieren, is there an example of confusion actually being caused?


 Please think
 as a contributor, not as QA programmer or data consumer (it's easy to
 check if the speed limit belongs to a waterway or not).

It's easy to think up potential for confusion whichever way we go on
this. Thinking as a contributor, the editing interfaces should make it
clear which units the user is stating/implying - as iD does, for
example. I definitely sympathise with Tom's reasoning for one unit per
tag, so I'd suggest there would need to be a strong case for this
mixed-units approach...

Dan


 And The knot is a non-SI unit that is accepted for use with the SI
 (https://en.wikipedia.org/wiki/Knot_%28unit%29)

 Pieren

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

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


Re: [Tagging] Release openstreetmap-carto v2.23.0

2014-10-29 Thread Dan S
Frederik,

The tagging and the wiki have been that way for many years.
http://wiki.openstreetmap.org/wiki/Bed_and_breakfast

I share your discomfort, since I think of a BB as a different thing
from a guesthouse. But over the years I've ended up using this tagging
since it's documented and appears to be how people tag. I guess it's
not Matthijs who made this decision...

Best
Dan

2014-10-29 20:55 GMT+00:00 Frederik Ramm frede...@remote.org:
 Hi,

 On 10/29/2014 09:34 PM, Matthijs Melissen wrote:
 * The tag tourism=bed_and_breakfast is no longer rendered - please use
 tourism=guest_house instead.

 Well - it might be your decision what to render and what not, but you
 shouldn't go so far as to request that people misrepresent reality in
 their mapping.

 A private residence where a single bedroom is made available to tourists
 is certainly no guest house and shouldn't be tagged as such! It is,
 and remains, a bed_and_breakfast.

 Bye
 Frederik

 --
 Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09 E008°23'33

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

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


Re: [Tagging] cleanup of the key natural

2014-10-07 Thread Dan S
Hi Martin,

OK, well since you requested comments: Firstly, I find it difficult to
understand what makes your proposed split more coherent or easy to
learn than thewiki- grouping that you propose to revert! By the way
please don't start a revert battle without first talking to that
editor.

Secondly, these tags are used so widely that I think you may have
missed your chance. For example it's not clear to me whether you would
accept natural=tree (see my first point), but since there are more
than 4 million of them, I think you are going to have to accept them.

If you want to make a change to the tagging of a massive number of
objects, you're going to need a _really_ persuasive argument. Not to
persuade me, but to persuade the crowd...

Just my 2p

Best
Dan


2014-10-07 14:42 GMT+01:00 Martin Koppenhoefer dieterdre...@gmail.com:
 According to the wiki, the natural key is currently a mixture of different
 aspects of something. The wiki states that it covers a selection of
 geological and landcover features.

 My suggestion is to keep only geological/geographical features in natural
 (all three, point features like peak and spring as well as linear features
 like natural=cliff or coastline and areas like
 natural=fell/wetland/beach/heath/bay/scrub/...) and to move the landcover
 features (those describing material rather than features, e.g. mud and
 sand) to a different key (my suggestion is landcover but there are also
 mappers advocating surface).

 A more coherent scheme would have a lot of advantages (easier to learn and
 understand because of more inherent logics, easier to maintain and extend
 and would allow to elaborate on different aspects for the same area object
 (i.e. will lead to more detailed data in the end)).

 ---

 Additionally I have spotted that recently a user has decided to group the
 features according to his interpretation:
 http://wiki.openstreetmap.org/w/index.php?title=Template:Map_Features:naturalaction=history

 I believe that this new grouping is disputable and propose to revert this
 change.
 ---


 Please comment.

 cheers,
 Martin

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


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


Re: [Tagging] Retag: craft=sweep = craft=chimney_sweep

2014-10-03 Thread Dan S
2014-10-03 12:06 GMT+01:00 Martin Koppenhoefer dieterdre...@gmail.com:

 2014-10-03 12:58 GMT+02:00 Tom Pfeifer t.pfei...@computer.org:

 I agree that craft=chimney_sweep is less ambiguous than =sweep
 alone, and with currently 24 instances in taginfo it would be a
 good time to change wiki and tags.
 +1

Yes, fine, I would say.

 what about chimney_sweeping to indicate the trade/craft (?) rather than
 the professional (person)?

Please, no! Chimney sweeping is not a phrase in British English,
whereas chimney sweep is. Plus, most of the craft=* tags use the
professional (person):
http://taginfo.openstreetmap.org/keys/craft#values

Dan

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


Re: [Tagging] governmental / public_administrative landuse are not commercial

2014-10-03 Thread Dan S
2014-10-03 18:14 GMT+01:00 Tom Pfeifer t.pfei...@computer.org:
 Martin Koppenhoefer wrote on 2014-10-03 15:32:

 2014-10-03 15:19 GMT+02:00 Tom Pfeifer:

 I feel the need for a landuse tag for governmental / administrative
 use,
 maybe in the context of further civic use.

 We do have office=administrative and office=government but no
 appropriate
 tag for the land they stand on. Often such buildings are surrounded by
 some land and often fenced off.

 not sure if office could also apply to the whole area (site) on which the
 office building stands (similar to how this is done with other amenities).


 I'd prefer to keep the office= tag to the building, or different offices in
 a building.

 Just to be sure: when writing about administration you are referring
 only to the public administration?


 Yes absolutely. Any commercial administration can keep the commercial
 landuse.

 Yes. I agree that the current practise of using commercial for all kinds
 of offices seems a bit strange, at least from a German point of view. I am
 not sure if the term commercial landuse is understood differently in
 English speaking countries. E.g.
 they do call their centres commercial district and central business
 district while in other cultures there might be a less business related
 term in use to articulate high density with mixed usage, but not focused on
 business (because there are also
 other features located typically, like theatres, museums and other culture
 related facilities).
 http://en.wikipedia.org/wiki/Commercial_district

 I see the introduction of a new, more specific key positive, e.g.
 landuse=public_administration

 +1

I would have suggested landuse=civic. Looking at taginfo, I don't see
it in use, though there is a small number of landuse=civil already.
(Plus other stuff of course...)

Dan

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


Re: [Tagging] (Soapy) Massage Parlour

2014-09-22 Thread Dan S
2014-09-22 7:29 GMT+01:00 Stephan Knauss o...@stephans-server.de:
 On 21.09.2014 11:04, Dan S wrote:

 It looks like there's this tag, including a tag suggested for your
 specific issue:
 http://wiki.openstreetmap.org/wiki/Tag:shop%3Dmassage

 please don't use shop=massage for this kind of places.

 I really don't want them to show up on a map next to Wat Pho massage just
 because the map creator does not take into account some additional tagging
 which says yes, it's tagged as a massage, but this tag tells you it isn't.

 Additional tags can specify something further, but should not change the
 meaning in general.

The original message said this kind of place offers bathing + massage
services plus the sexual stuff. My advice was based on that
description. You seem to be saying that these places _don't_ offer
massage services. I don't actually know which of these is true!

Dan

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


Re: [Tagging] (Soapy) Massage Parlour

2014-09-21 Thread Dan S
Hi -

It looks like there's this tag, including a tag suggested for your
specific issue:
http://wiki.openstreetmap.org/wiki/Tag:shop%3Dmassage

Best
Dan

2014-09-21 4:23 GMT+01:00 Mishari Muqbil mish...@mishari.net:
 Hi,

 Thailand has these places called entertainment complexes[1]  that
 offers bathing + massage services and quite often the expectation is
 that there will be sexual services offered. However, I don't want to tag
 them as brothels as prostitution on the premises is legally not allowed[2].

 I propose to tag this as leisure=massage_parlour since that's what the
 Thai English dictionary calls them[3] but I don't want it to be mistaken
 for more family friendly establishments in other parts of the world.
 Colloquially these places are called soapy massage so perhaps
 leisure=soapy_massage? :)

 One reason why they should be mapped is just how prominent they are as
 landmarks in general. For example, here's one called Utopia
 http://www.mapillary.com/map/im/z1A8OOUw01E5Jc84Mff-1Q this one's La
 Defense http://www.mapillary.com/map/im/ho84IFdUxupke-6pwrWW3g and
 Colonze http://www.mapillary.com/map/im/469ttdMVw4_1o3vkuvE_xw

 Any thoughts?

 [1] https://en.wikipedia.org/wiki/Prostitution_in_Thailand#Ab_Ob_Nuat
 [2]
 https://en.wikipedia.org/wiki/Prostitution_in_Thailand#The_Entertainment_Places_Act
 [3]
 http://th.w3dictionary.org/index.php?q=%E0%B8%AA%E0%B8%96%E0%B8%B2%E0%B8%99%E0%B8%AD%E0%B8%B2%E0%B8%9A%E0%B8%AD%E0%B8%9A%E0%B8%99%E0%B8%A7%E0%B8%94
 --
 Best regards
 Mishari Muqbil
 EE32 64BD 7D1F 5946

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

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


Re: [Tagging] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)

2014-09-21 Thread Dan S
2014-09-21 0:49 GMT+01:00 Eugene Alvin Villar sea...@gmail.com:
 On Sun, Sep 21, 2014 at 7:09 AM, p...@trigpoint.me.uk wrote:

 Dormitories are rooms with multiple beds, usually bunk beds and associated
 with youth hostels,  certainly not suitable for student accommodation where
 there is typically one student in a room, maybe two but they are certainly
 not dormitories.

 What you're saying is British English usage. Here in the Philippines,
 dormitories are understood to be buildings primarily for students.

Thanks. So we've re-confirmed that the word dormitory has some
ambiguities that might be problematic, especially considering that OSM
is based on British English.

Eugene points out sport=soccer which is a good example of OSM
deliberately avoiding ambiguities, since in that case the common term
football has one meaning in US and one in UK. In that case we
avoided the British term as a special case, to avoid the ambiguity.
Here dormitory is the ambiguous term.

But that's all fine, since remember that Hno's tag proposal has
already been altered to amenity=student_accommodation.
https://wiki.openstreetmap.org/wiki/Proposed_features/amenity%3Dstudent_accommodation
I agree with fly that it'd be nice to have a tag which didn't fix the
profession (so that it could be used for nurses/lecturers/etc) but
maybe that's not so bad.

Cheers
Dan

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


Re: [Tagging] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)

2014-09-21 Thread Dan S
2014-09-19 16:15 GMT+01:00 Martin Koppenhoefer dieterdre...@gmail.com:


 2014-09-19 14:22 GMT+02:00 Dan S danstowell+...@gmail.com:


  for buildings:   building=residential + residential=university +
 operator=*
 OR
  for sites:   landuse=residential + residential=university + operator=*

 Note that the same scheme seems to me to work well for building and for
 landuse.



 I am not sure if this works. Have you been looking at current values for
 the residential key? These are the ones with more than 100 uses:

 rural http://taginfo.openstreetmap.org/tags/residential=rural
 78 141

 -

 urban http://taginfo.openstreetmap.org/tags/residential=urban
 12 698

 -

 garden http://taginfo.openstreetmap.org/tags/residential=garden
 3 805

 -

 gated http://taginfo.openstreetmap.org/tags/residential=gated
 884

 -

 apartments http://taginfo.openstreetmap.org/tags/residential=apartments
 231

 -

 single_family
 http://taginfo.openstreetmap.org/tags/residential=single_family
 197

 -

 detached http://taginfo.openstreetmap.org/tags/residential=detached
 133




Thanks Martin. Yes I did look at these. NONE of them have a wiki page, nor
does the residential=* tag in general, so I'm at a loss to work out what is
intended by them!

* Surely the rural/urban distinction is judged by location? Could you have
residential=rural in the town centre? Maybe (since the tag isn't
documented) but I would guess not. So what's the tag for? Does it designate
context, building style, building density...?

* Surely apartments/detached/single_family should be properties of the
building objects?

* residential=garden I quite like, but it seems to duplicate leisure=garden
and it seems strange to me to consider gardens as residential since
usually no-one lives in the garden. I wonder if it was ever discussed much.

* residential=gated I like. In theory you can use barrier=* and access=* to
indicate the unusual access constraints for gated residences, but actually
it's not always obvious as that, since non-gated communities might also
have fences etc. So this tag seems to me like it might make a useful
distinction.



 There are already at least 3 different systems (one for rural / urban and
 one for the building typology (detached / single_family / apartments) and
 one for gated communities (what's this, socio-economic aspect of urbanism
 maybe?). Now you seem to be adding yet another one, university for
 student's appartments (not really self explaining IMHO).


So if not self-explaining, what misunderstandings of
residential=university could happen? It seems quite self-explaining to
me, so I'd be grateful if you could offer your perspective of potential
misunderstandings of residential=university.



 I would use a specific tag for the building typology (e.g.
 building=dormitory or student_accomodation or similar if the building was
 built as such) and another one if it is actually used as such (e.g. under
 the amenity key as suggested by Tobias).


Understood. For the building, at least, the subtag works, if used to
indicate building typology.



 I don't see this as a case for adding a specific landuse value, but I do
 agree that refining the generic residential into more differentiated
 values by subtagging might be a general option (regardless of this
 particular case of student accomodation), e.g. differentiate according to
 density and

 structure (open / closed, not sure about the precise term in English, for
 reference see these two pictures:
 open (=space between buildings)
 http://de.wikipedia.org/wiki/Offene_Bauweise_%28Baurecht%29#mediaviewer/File:Offene_Bauweise.png
 closed (buildings without space between them):
 http://de.wikipedia.org/wiki/Geschlossene_Bauweise_%28Baurecht%29#mediaviewer/File:Geschlossene_Bauweise.png


In British English this seems to me to  detached vs semi-detached vs
terrace (though there's not a 1:1 concept match). Again, though, it's not
clear to me why you'd want to tag residential areas as having these
properties, since they're already commonly indicated via the tags/geometry
of the building objects.

Thanks again for your detailed reply.

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


Re: [Tagging] (Soapy) Massage Parlour

2014-09-21 Thread Dan S
Hi,

Well, that suggestion specifies access limits (i.e. only males age 21
or more), and if those are true facts and they're what you want to
indicate, then go ahead. The access limits don't really tell you if
something is soapy or not, but if you decide you only want to imply
that and not to state it explicitly, your approach sounds OK to me.

However, there's NO reason to use amenity=massage_parlour when
shop=massage already exists. Please use it. You said you want to avoid
confusion between soapy and family-friendly, and your age-restriction
works for that, no need to create a duplicate tag.

Best
Dan


2014-09-21 14:52 GMT+01:00 Mishari Muqbil mish...@mishari.net:
 Hi,

 I saw that, but I'm not convinced it's the right approach as what I'm
 referring require a specific massage parlor license to operate as
 opposed to a regular traditional massage establishment which is more
 suited for shop=massage. I think it would be akin to saying a
 convenience store and supermarket can all be tagged the same way. Also,
 I'm not comfortable with using sexual as it could be libelous to state
 that something illegal is taking place in these establishments (for
 example, you won't do shop=convenience+marijuana=yes in most parts of
 the world).

 How about something like a combination of:
 amenity=massage_parlour
 male=yes
 female=no
 min_age=21

 This should be quite accurate.

 On 21/9/14 16:04, Dan S wrote:
 Hi -

 It looks like there's this tag, including a tag suggested for your
 specific issue:
 http://wiki.openstreetmap.org/wiki/Tag:shop%3Dmassage

 Best
 Dan

 2014-09-21 4:23 GMT+01:00 Mishari Muqbil mish...@mishari.net:
 Hi,

 Thailand has these places called entertainment complexes[1]  that
 offers bathing + massage services and quite often the expectation is
 that there will be sexual services offered. However, I don't want to tag
 them as brothels as prostitution on the premises is legally not allowed[2].

 I propose to tag this as leisure=massage_parlour since that's what the
 Thai English dictionary calls them[3] but I don't want it to be mistaken
 for more family friendly establishments in other parts of the world.
 Colloquially these places are called soapy massage so perhaps
 leisure=soapy_massage? :)

 One reason why they should be mapped is just how prominent they are as
 landmarks in general. For example, here's one called Utopia
 http://www.mapillary.com/map/im/z1A8OOUw01E5Jc84Mff-1Q this one's La
 Defense http://www.mapillary.com/map/im/ho84IFdUxupke-6pwrWW3g and
 Colonze http://www.mapillary.com/map/im/469ttdMVw4_1o3vkuvE_xw

 Any thoughts?

 [1] https://en.wikipedia.org/wiki/Prostitution_in_Thailand#Ab_Ob_Nuat
 [2]
 https://en.wikipedia.org/wiki/Prostitution_in_Thailand#The_Entertainment_Places_Act
 [3]
 http://th.w3dictionary.org/index.php?q=%E0%B8%AA%E0%B8%96%E0%B8%B2%E0%B8%99%E0%B8%AD%E0%B8%B2%E0%B8%9A%E0%B8%AD%E0%B8%9A%E0%B8%99%E0%B8%A7%E0%B8%94
 --
 Best regards
 Mishari Muqbil
 EE32 64BD 7D1F 5946

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

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


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

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


[Tagging] Feature Proposal - RFC - residential=gated

2014-09-21 Thread Dan S
Hi all,

Motivated by the discussion around residential=* sub-tagging, I
thought it would be useful to get a bit more clarity, by taking some
existing sub-tagging and putting it through RFC.

Here is a proposal for residential=gated:
http://wiki.openstreetmap.org/wiki/Proposed_features/residential%3Dgated

I chose this tag because it's already used quite a bit, its meaning
seems clear to me, and it seems potentially useful, though I can't
predict if the community more generally will consider it useful.

Please comment on the wiki talk page.

Thanks
Dan

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


[Tagging] RFC: Student accommodation building

2014-09-21 Thread Dan S
Hi all,

Following the tagging conversation about student accommodation
buildings, I created a proposal wiki page, to document the different
tagging perspectives, and maybe one day work towards half a consensus
;)

https://wiki.openstreetmap.org/wiki/Proposed_features/Student_accommodation_building

(Note: this is about tagging a building type; it's separate from Hno's
amenity=student_accommodation proposal which aims to tag the usage.)

Best
Dan

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


Re: [Tagging] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)

2014-09-20 Thread Dan S
2014-09-19 15:52 GMT+01:00 Tobias Knerr o...@tobias-knerr.de:
 On 19.09.2014 14:22 Dan S wrote:
  for buildings:   building=residential + residential=university + operator=*
 OR
  for sites:   landuse=residential + residential=university + operator=*

 Note that the same scheme seems to me to work well for building and for 
 landuse.

 I thought this had been discussed on tagging recently, but I can't
 find it, all I can find is the RFC for amenity=dormitory, currently
 used 263 times. (I will add that dormitory is certainly a little odd
 from a British English point of view, notwithstanding the comments
 already made to the RFC.)

 That proposal now suggests amenity=student_accommodation, precisely
 because of the oddness involved with the term dormitory.

Ah yes, thanks. So now it assumes the occupants are students and not
lecturers ;)

(I'm just being cheeky. I know of universities in which lecturers do
stay in similar accommodation blocks, but that point is not important
enough to argue about...)

 Personally, I prefer using the amenity key rather than building or
 landuse. Landuse lacks the implication that this is one distinct
 facility

OK. I understand why you'd prefer amenity for tagging the usage. If
that tag gets accepted I guess I should use that instead of landuse,
and I understand your arguments there. I feel differently, because I
feel the analogy between a housing estate and a multi-building
student halls site is quite a strong analogy, neatly represented by
a named area of landuse=residential. But there we go.

 and building values are not supposed to represent usage, but how the building 
 is built.

This week I stayed in university accommodation (even though I'm not a
student ;), and the buildings were purpose-built student halls, so it
would be nice to tag the building appropriately. Alternatives include:
(a) building=residential (without subtagging), which is fine if vague;
(b) building=apartments, which is tolerable but not quite appropriate;
(c) building=dormitory which is in use, but it's US English, and to
my Brit English mind just feels wrong. Sorry to moan about the US/UK
difference, but it is indeed a difference:
http://dictionary.cambridge.org/dictionary/british/dormitory,
http://www.oxforddictionaries.com/definition/english/dormitory
(d) building=residential + residential=university, the approach I
was using recently. Not as widely used. It has an advantage of
graceful fallback (meaning data-users can understand the objects as
building=residential even if they ignore the subtag).

I still prefer (d) though if building=dormitory becomes widely
accepted then I guess I shall have to swallow that loss for British
english!

Cheers
Dan

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


[Tagging] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)

2014-09-19 Thread Dan S
Hi all,

I have been fixing some university tagging (Sheffield contained
hundreds of amenity=university!). For student accommodation, I have
been using

 for buildings:   building=residential + residential=university + operator=*
OR
 for sites:   landuse=residential + residential=university + operator=*

Note that the same scheme seems to me to work well for building and for landuse.

I thought this had been discussed on tagging recently, but I can't
find it, all I can find is the RFC for amenity=dormitory, currently
used 263 times. (I will add that dormitory is certainly a little odd
from a British English point of view, notwithstanding the comments
already made to the RFC.)

residential=university has been used by a few people (99 objects, says
overpass). 33 of these are building=residential, 53 are
landuse=residential.

It's clear I'm not the only one using this pattern, though it's not an
approach that's officially adopted as far as I know. To me it seems
very meaningful usage, compatible with existing tagging, and covers
the intended use of amenity=dormitory except for monasteries ;)

Thoughts?

Best
Dan

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


Re: [Tagging] default value for oneway

2014-08-28 Thread Dan S
2014-08-28 14:45 GMT+01:00 Xavier Noria f...@hashref.com:
 On Thu, Aug 28, 2014 at 3:39 PM, Dave F. dave...@madasafish.com wrote:

 I wish people in OSM would stop making things up, believing it makes their
 point of view stronger.

 What?

 I am not assuming one-way would be a better default. Nor I am assuming
 anything about the world at large. What are you talking about?

Let's put all that aside.


 I only asked questions:

 1) Which is the rationale? Not because I think it is wrong, but to
 understand it!

As Peter said, the default for services using OSM is always to assume
a way is _not_ oneway unless tagged otherwise.


 2) In cities and towns where two-way streets are exceptional like
 Barcelona or Madrid, are people expected to tag them no? The
 motivation for this question is that there seems to be the convention
 not to tag them, and therefore you cannot tell the confirmed ones from
 the untagged ones.

No, I think more likely is that local mappers have not considered it a
priority to add the oneway tags, or maybe there are so many that it's
a difficult job that isn't finished yet.

Best
Dan

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


Re: [Tagging] separator for addr:housenumber=*

2014-08-24 Thread Dan S
2014-08-24 11:05 GMT+01:00 Friedrich Volkmann b...@volki.at:
 On 20.08.2014 10:18, Holger Jeromin wrote:
 Andreas Labres wrote on 20.08.2014 04:10:
 On 19.08.14 23:17, fly wrote:
 but 265-267 is wrong

 Read as tagging 265-267 alone is wrong.

 Disagree. addr:housenumber is the official number given to that building. 
 And if
 it's 265-267, then addr:housenumber=265-267 is the only correct 
 implementation
 of this.

 But osm db needs a hint that 266 is missing. That is obvious on the
 street (by looking at the right and left building) but not in the data.

 The OSM db does not need to know about (the meaning of) housenumbers. Its
 sole purpose is to store data. In this case, the housenumber is 265-267,
 literally! This is not a shortcut for 265;266;267.

Agree strongly - I think it is a mistake to say osm db needs a hint
that 266 is missing when considering an address which is officially
labelled as 265-267. If addresses truly are compounds like that (and
not number-ranges) then we can't really make standard inferences about
which numbers are present and which are missing.


 Applications should not attempt to resolve housenumbers that way.

...unless they have been explicitly marked with addr:interpolation,
which tells us explicitly that they should be resolved :) - discussed
in a separate thread recently.

Dan

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


Re: [Tagging] separator for addr:housenumber=*

2014-08-24 Thread Dan S
2014-08-24 11:24 GMT+01:00 Friedrich Volkmann b...@volki.at:
 On 18.08.2014 22:36, Janko Mihelić wrote:
 What happens when the same entrance has two housenumbers, each from its own
 street? I'm sure this exists somewhere.

 The housenumber belongs on the building or building part, not the
 entrance(s). When a building (part) has two equivalent addresses, use the
 addr:* schema for one address and the addr2:* schema for the other.

There are quite a lot of objects in the database that disagree with you ;)
http://taginfo.openstreetmap.org/keys/entrance#combinations

This is one of those cases which probably has a strong flavour of
country- or location-specific conventions. There are many addresses in
London which, if I had to tag them as buildings or building parts, I
could not stay sane! On the ground, around here, they are _very_ often
associated with multiple entrances on a building and not with
explicitly indicated building parts.

Best
Dan


  I propose to deprecate comma and use semi-colon instead to 
 harmonize
  our data structure and allow QA software to find problematic values.


 +1

 Semicolons seem more consistent than commas, but I doubt that either of them
 are applicable for real-world addresses. In Austria, we use dashes as
 separators, as Andreas pointed out; except when housenumbers relate to
 different streets (see above).

 --
 Friedrich K. Volkmann   http://www.volki.at/
 Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

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


Re: [Tagging] separator for addr:housenumber=*

2014-08-24 Thread Dan S
Hi Christian,

As I've already mentioned, in the other thread we discussed a
disambiguation. I would suggest that if you find only

  addr:housenumber=265-269

then you can't really assume any interpolation, and I would argue that
even transforming it to 265 and 269 is going beyond what the data
tells you. However, even though it is going beyond the data, it may
be a sensible thing to do if you are working specifically on a
geocoding system. (That is application-dependent.)

The problem with going beyond the data is that there may be
housenumbers which officially have dashes in, but would be meaningless
if broken up. (I found these ones for example:
http://taginfo.openstreetmap.org/compare/addr:housenumber=1-a/addr:housenumber=2-a/addr:housenumber=1-b/addr:housenumber=2-b
- but there are only a tiny quantity so these examples are not too
serious.)

On the other hand, if you see an object tagged

  addr:housenumber=265-269
  addr:interpolation=odd

then we can be quite confident that the mapper intended you to
interpret this as 265 and 267 and 269.

Best
Dan


2014-08-24 12:31 GMT+01:00 Christian Quest cqu...@openstreetmap.fr:
 In that case, how should application resolve housenumbers ?
 What tagging do you propose to allow it ?

 I'm working on the BANO project who aims to create a nationwide address
 database, using in part OSM data.
 I already have to deal with this kind of addr:housenumber=*

 For the moment, 265-269 is transformed into 265 and 269 only, but having
 some tag based clue that we have an odd number range meaning that 267 is
 located at the same place would be a real benefit.



 2014-08-24 12:05 GMT+02:00 Friedrich Volkmann b...@volki.at:

 On 20.08.2014 10:18, Holger Jeromin wrote:
  Andreas Labres wrote on 20.08.2014 04:10:
  On 19.08.14 23:17, fly wrote:
  but 265-267 is wrong
 
  Read as tagging 265-267 alone is wrong.
 
  Disagree. addr:housenumber is the official number given to that
  building. And if
  it's 265-267, then addr:housenumber=265-267 is the only correct
  implementation
  of this.
 
  But osm db needs a hint that 266 is missing. That is obvious on the
  street (by looking at the right and left building) but not in the data.

 The OSM db does not need to know about (the meaning of) housenumbers. Its
 sole purpose is to store data. In this case, the housenumber is 265-267,
 literally! This is not a shortcut for 265;266;267. Applications should
 not
 attempt to resolve housenumbers that way.

 --
 Friedrich K. Volkmann   http://www.volki.at/
 Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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




 --
 Christian Quest - OpenStreetMap France

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


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


Re: [Tagging] Ambiguous surface=wood

2014-08-22 Thread Dan S
I'd say it's very rare that wood could be interpreted as possibly
meaning woodchip. Woodchip has very different material properties,
and different affordances for travellers. A little bit like saying
wood might mean sawdust ;)

surface=woodchip is used more often than surface=woodchips, though
neither of them is used very much at the moment:
taginfo.openstreetmap.org/compare/surface=woodchip/surface=woodchips

I would advocate surface=woodchip (singular), and preserve the
existing meaning of surface=wood as planks.

Maybe we should document surface=woodchip?

Just my 2p
Dan


2014-08-22 6:53 GMT+01:00 Mateusz Konieczny matkoni...@gmail.com:
 I discovered* that surface=wood is ambiguous and may mean two very different
 things:
 1) paths with wood chips
 2) paths paved with wooden planks (for example
 https://pl.wikipedia.org/wiki/Plik:Bernatek_foot-bridge_%28Love_padlocks%29,_Krakow,_Poland.jpg
 )

 I want to tag in way that would be clear, now I consider using for the
 second
 situation [surface=wood; wood=planks] or [surface=planks] and
 [surface=wood; wood=chips] or [surface=woodchips] for the first one.

 Currently wiki mentions only situation (2).

 *http://forum.openstreetmap.org/viewtopic.php?pid=444548#p444548

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


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


Re: [Tagging] interpolated housenumbers on single objects

2014-08-20 Thread Dan S
Hi,

Thanks all for your thoughts. Will and Holger seem to have the same
approach as me, which gives me the confidence to edit the wiki and at
least document this approach:
http://wiki.openstreetmap.org/wiki/Addresses#Buildings_with_multiple_house_numbers

Hopefully I've done it in a way which won't anger those who dislike the idea: ;)

Dan


2014-08-19 22:45 GMT+01:00 Will Phillips wp4...@gmail.com:
 I often use the addr:interpolation tag on entrances or buildings. I don't
 understand some people's objection to this. I don't see any ambiguity: if
 the addr:interpolation tag is present the addr:housenumber tag represents a
 range, otherwise it should be interpreted as a single address. As someone
 who maps addresses regularly I find this a quick and convenient way to do
 it. All the alternatives are either cumbersome for the mapper, or are hacky,
 because they involve putting addresses at arbitrary positions within a
 building.

 I find that by far the most time consuming part of surveying house numbers
 is actually adding the data afterwards and for this reason I think we should
 be trying to make the tagging quick and straightforward for mappers wherever
 possible. To me restricting the use of addr:interpolation seems an
 unnecessary rule that makes things more difficult. Additionally, we should
 avoid making it unnecessarily complicated for mappers to add useful
 information. For example, if numbers 20 to 40 on a street are accessed
 through a particular door, I want to tag that explicitly, because it's
 useful for routing and accessibility. Advocating tagging that forces me
 instead to stick the addresses at an arbitrary position within the building
 outline is unhelpful.

 The proposed Node relation mentioned by Janko Mihelic is I think a useful
 idea for certain situations. For example, I've encountered cases where
 addresses accessed through a single door have more than one postcode, so
 can't be accurately represented on a single node. These relations would
 allow all the addresses to be associated with the entrance. However, I'm not
 convinced it's a good solution for simpler cases because making mappers
 create separate nodes for all the numbers in a range and then linking them
 together with a relation seems over-complicated.

 The wiki documentation for using addr:interpolation on single objects has
 been changed several times. As Dan noted, the current version recommends
 against it. A few months ago I reinstated an earlier version that recognised
 and briefly explained this usage, but it was removed by a user who wrote it
 was ambiguous, but they didn't really explain why they thought it so. I
 propose adding it again.


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

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


Re: [Tagging] interpolated housenumbers on single objects

2014-08-20 Thread Dan S
2014-08-20 11:11 GMT+01:00 Ilpo Järvinen ilpo.jarvi...@helsinki.fi:
 On Wed, 20 Aug 2014, Will Phillips wrote:

 On 20/08/2014 00:02, Martin Koppenhoefer wrote:
   Il giorno 19/ago/2014, alle ore 23:45, Will Phillips wp4...@gmail.com 
   ha
   scritto:
  
   I find that by far the most time consuming part of surveying house
   numbers is actually adding the data afterwards and for this reason I
   think we should be trying to make the tagging quick and
   straightforward for mappers wherever possible.
 
  Which editor are you using?

 I've always used JOSM.

 Speaking to other mappers, they usually agree that data input for addresses
 takes 2-3 times as long as the actual surveying.

 My experience is that it takes even longer than that especially if the
 area contains small houses rather than bigger buildings. Drawing them
 all is very slow compared with inputting addr data. I'd say 10-20x.

 There are various reasons for this, some specific to mapping where I
 live (England).

 Why it takes a long time -
 1. The usual problems of reconciling the surveyed data with existing data and
 the aerial imagery.
 2. Adding other detail at the same time. In particular, adding buildings. It
 would be much quicker if I chose just to add nodes.

 So true.

 With the experience of tens of thousands addresses survey, this is really
 big obstable. Some of my surveyed data rotted(!) because the drawing delay
 hindered immediate input. That is, I lost the near-term memory about
 details before I could draw all the building I could easily survey
 addresses for.

 This is also the reason I really get almost angry when people oppose
 importing building without addresses (because they find them useless
 without other details such as addresses included already during the
 import). I doubt that such people have much experience on surveying
 addresses and trying to draw the buildings while inputting the addr data
 to OSM.

I agree with these observations from your experience. Back in January
I said I suspected building outlines were unimportant*. But that was
before I started heavily address-mapping! My opinion now is that a
two-step process works really well: first pass gets basic building
outlines (from aerials or maybe even from imports), then second pass
is address mapping on the ground, which will probably also include
lots of changes to the building outlines. But the first pass makes the
second pass a lot easier - both the surveying and the data entry.

Best
Dan

* http://www.openstreetmap.org/user/mcld/diary/20663

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


Re: [Tagging] separator for addr:housenumber=*

2014-08-18 Thread Dan S
2014-08-18 15:04 GMT+01:00 fly lowfligh...@googlemail.com:
 Hey

 On the English wiki page [1] comma is the proposed separator for
 several values of addr:housenumber.

 This contradicts our rule of using semi-colon as separator of values
 and I do not have a clue why.

Probably led by what users are already doing, and probably because
renderers produce natural-looking results for places where commas are
conventional. This could be considered tagging-for-the-renderer, if it
weren't already an established micro-convention. I agree with you it's
out of step with convention for other tags.

 I propose to deprecate comma and use semi-colon instead to harmonize
 our data structure and allow QA software to find problematic values.

 What do you think ?

I don't mind. I'm happy with your proposal, if there's enough support for it.

To prevent the tagging-for-the-renderer, it would help if the main
styles would automatically convert 1;3 to 1, 3 when rendering -
I'd be surprised if they already do that, but it would help your
proposal actually happen!

Dan

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


[Tagging] interpolated housenumbers on single objects

2014-08-18 Thread Dan S
Hi taggers,

When mapping recently, I encountered many addresses which contain
multiple housenumbers behind single entrances. I've used interpolation
before, and used it in the traditional sense to map a range along a
row of houses. But here we have an interpolated range on a single
object, not spread across a spatial extent.

I intuitively re-used the addr:interpolation tag, but applied it to a
single object. For example we might have this on a single node or a
building:

  addr:housenumber=100-126
  addr:interpolation=even
  addr:street=Malmesbury Road

Please note that:
 * These house numbers are _not_ flat numbers. That is clear on the ground.
 * From the outside of the block there's no spatial distribution of
those numbers 100-126 so they can't sensibly be represented as a
traditional interpolation from one addr to another.

Today (thanks to Fly's email about something else) I noticed that the
wiki says this tagging shouldn't be used. It says:

 You may also add a short way and use addr:interpolation=*. Don't specify the 
 range (e.g., 10-95) directly in the addr:housenumber=* tag. It is 
 impossible to distinguish such ranges from house numbers that officially 
 contain a dash.

I beg to differ. it _is_ possible to distinguish such ranges, because
of the addr:interpolation tag. I certainly understand that software
doesn't currently know that an addr:interpolation tag indicates it may
parse addr:housenumber as a range, but this tagging seemed so
plausible to me that I didn't question it.

Adding a short fake way so that there are addr endpoints seems like a
total hack to me.

How would you tag it?

Best
Dan

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


Re: [Tagging] Mapping cave tunnels passable by human

2014-08-14 Thread Dan S
2014-08-14 11:40 GMT+01:00 Mateusz Konieczny matkoni...@gmail.com:
 2014-08-14 12:31 GMT+02:00 Martin Vonwald imagic@gmail.com:

 2014-08-14 12:25 GMT+02:00 André Pirard a.pirard.pa...@gmail.com:

 On 2014-08-14 11:08, Janko Mihelić wrote :

 Well first, tunnel=yes is obviously wrong. We need to replace this with
 cave=yes. Other than that, I have no problems with this. If a cave has two
 cave entrances, then information that they are connected by footpaths is
 valuable information.

 Obviously?  Regarding paths and waterways, especially ones fitted up for
 tourism, I wonder...


 Maybe not completely obvious, but I would agree with Janko. In my opinion,
 a tunnel is man-made, while a cave is not.


 Neither OSM wiki nor Wikipedia restricts it this way. There is even section
 about natural tunnels - see
 https://en.wikipedia.org/wiki/Tunnel#Natural_tunnels (though caves are not
 mentioned there).

 Note, I am not a native speaker - maybe it sound terrible, worse than for
 example using highway as tag also for private roads.

As a native speaker I may as well chip in, and say I have no problem
at all with tunnel referring to a natural tunnel as part of a cave
system.

 But I see absolutely no benefit from a completely separate tagging (that
 nobody would support).

Well, no-one ever supports new tagging, the question is if it's
needed. But I agree, I can't see a benefit keeping it separate.

Dan

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


Re: [Tagging] Mapping cave tunnels passable by human

2014-08-14 Thread Dan S
2014-08-14 12:01 GMT+01:00 Friedrich Volkmann b...@volki.at:
 On 14.08.2014 07:29, Mateusz Konieczny wrote:
 I added to http://wiki.openstreetmap.org/wiki/Cave#Tagging_in_OSM how
 these may be mapped

 Given that you want to discuss wiki changes, you should start the discussion
 before you actually do the changes. You should also refer to this mailing
 list thread in the comment of your wiki change, or in the talk page. I
 received an automated notification that you changed the wiki and did not
 know about the mailing list thread, so I corrected the wiki. Now I am
 surprised that there's a discussion in another medium.

 (tunnels that are available for humans but closed for typical
 tourists may be mapped as highway=path with tunnel=yes and access=private,
 and routes available for tourists as highway=footway (highway=steps) with
 tunnel=yes).

 I am not sure about English terminology. In German, we call natural cavities
 Höhlen (caves), and artificial cavities Stollen (adits?). A straight
 Stollen with an entrance on each end is a Tunnel (tunnel). I think that
 the meaning of the English word tunnel is just the same as in German. In
 that case, tunnels and caves are mutually exclusive.

Not in my native opinion, but let's see what other natives think too.

 I also do not understand why you connect highway=path with private access.
 Paths may or may not be publicly accessible, as are footways. Footways are
 by definition even more restricted, namely to pedestrians.

 I think that it is an obvious idea, but wiki claimed that At the moment
 there just a
 tag to map the entrance to a cave. despite fact that existing tags fit well.

 No, they do not fit. Caves are complex three-dimenional structures. In most
 caves there are no paths. You go or climb or rope down whereever you feel 
 like.

This is the same as with a pedestrian square - there's no specific
route in the square and you go wherever you feel. However it's useful
to make them part of the OSM database, both for showing their
existence and to help with various routing applications.

 I am pretty sure that it is a good idea, but maybe there is some superior
 scheme or
 I missed something.

 There is no scheme, and I doubt that cave maps belong in a geo database.
 Cave maps are very detailed, and there are special applications for cave
 rendering. For Austria, there's also a database called Spelix, accessable
 via web browser. It contains cave surveys and maps, photos and other data.
 Getting all of that data to OSM would mean continuous duplicated effort and
 yet the data in OSM will never be as complete as the original data. I have
 surveyed a lot of caves and for sure I will not draw all of my cave maps
 again only to get them into OSM. If you are interested in caves, get access
 to dedicated cave databases.

It's great that these specialist databases exist! But as I imply
above, I'd say it is still of value to tag some cave features/routes
in OSM. We can be happy to do this, without attempting the level of
detail in the specialist databases.

 I wonder about adding something that would denote that way is part of cave,
 maybe natural=cave_tunnel?

 See above. A tunnel is not a cave. If you want to express that a way is
 underground, use layer=-1.

I'm afraid layer=-1 does not express that a feature is underground. It
expresses that a feature is lower than all features at layer=0+, but
there's no guaranteed relationship with ground level. There are quite
a few objects with the implicit layer=0 but which are not at ground
level (e.g. tunnel=culvert items: http://overpass-turbo.eu/s/4zE).

Best
Dan

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


Re: [Tagging] Climbing access path

2014-08-08 Thread Dan S
2014-08-08 10:21 GMT+01:00 k4r573n k4r5...@googlemail.com:
 On 07.08.2014 12:05, Tom Pfeifer wrote:
 If I understand Karsten correctly, the limitation is not about payment,
 it is to limit the number of people using this path. This would be
 typical for climbing crags in
 http://wiki.openstreetmap.org/wiki/Conservation
 areas.

 A typical example is the sandstone climbing in Saxonia/Germany, which
 is in
 a national park that even has a core zone.
 http://www.openstreetmap.org/relation/1595534

 The agreement between the protectionists and the climbing associations
 is that only people destined to climb should leave the hiking paths
 marked for the general public and use those narrow access paths.

 Thus it would be possible to tag
 access=destination
 which could then be specified with
 destination=climbing

 Tom - yes you understood me right :)
 There is no one who check whether your a climber or not or want to have
 a fee - but these path are not aimed to be used by the general public.

 I admit that access=customers doesn't fit here so
 summed up we have these approaches:
   access=destination
   destination=climbing

 or
   access=climbers

 or
   access=no
   climbing=yes

 I'm ok with each of them but which one should be documented in the wiki

I'd vote for the first one (destination). I'm not keen on the third
one since climbing=* would need to become widely recognised as an
access tag, which doesn't feel very scaleable.

Best
Dan

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


Re: [Tagging] Climbing access path

2014-08-07 Thread Dan S
The sac_scale is about difficulty, not permission. I assume from
Karsten's original message that only climbers are permitted to use
those paths. If so, then access=customers is appropriate, and
customers=climbers seems helpful...

Dan

2014-08-07 9:50 GMT+01:00 Marc Gemis marc.ge...@gmail.com:
 Wouldn't it be better to use the sac_scale [1] instead of artificially
 limiting it to customers ?

 regards

 m

 [1 ]http://wiki.openstreetmap.org/wiki/Key:sac_scale


 On Thu, Aug 7, 2014 at 9:51 AM, k4r573n k4r5...@googlemail.com wrote:

 I would like to distinguish between hiking paths and climbing_access
 paths.
 In my area only climbers are allowed to use the paths to access the
 cliffs.

 Therefore I thought of this tagging for climbing_access paths:
   access=customers
   customers=climbers

 what I found so far:
   path=climbing_access
   taginfo found 391 items
   eg here:
   http://overpass-turbo.eu/s/4sK

 any suggestions how we should map this?

 Karsten

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



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


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


Re: [Tagging] Research laboratory

2014-08-05 Thread Dan S
Hi Pierre-Alain,

That's a good question. I thought I'd search a couple of names to see
how they are tagged. Here is a selection:

INRIA (in France):
 * office=research  http://www.openstreetmap.org/node/2529263700
 * office=government http://www.openstreetmap.org/way/124838923
 * landuse=commercial (huh?) http://www.openstreetmap.org/way/52380877

Fraunhofer (in Germany):
 * office=research http://www.openstreetmap.org/way/146020861
 * office=research http://www.openstreetmap.org/node/2869588612
 * landuse=industrial http://www.openstreetmap.org/way/244665212
 * landuse=commercial (huh?) http://www.openstreetmap.org/way/62306004

(I haven't listed entries which don't really have any tagging.)

In my opinion office=research is a good choice, and it is already used a lot:
http://taginfo.openstreetmap.org/compare/office=research/industrial=laboratory/office=laboratory

Best
Dan

2014-08-05 11:06 GMT+01:00 Pierre-Alain Dorange pdora...@mac.com:
 Hello,

 First sorry for my poor english, i was french (no one is perfect).

 I was looking to tag Research Laboratory (either private/commercial
 and public), part or not part of a univercity. This Research laboratory
 are big one with industrial facility (like plant) for biological,
 geological or nuclear research.

 I do not find satisfaying tags for that (but perhaps i do not search the
 right way).

 OSM wiki do not have info about that (except a 2008 proposal [1])

 Taginfo show me :

 amenity=laboratory (66)
 building=laboratory (10)
 office=laboratory , but it was pure RD (not industrial ones)
 health_facility:type=laboratory (138) : but only for medical research
 research_institution=yes (2008 proposal)
 laboratory=*

 For big/industrial research lab i would use
 industrial=laboratory + laboratory=nuclear
 inside a landuse=industrial
 For small ones (not industrial) :
 building=laboratory + laboratory=nuclear

 What about this ?
 --
 Pierre-Alain Dorange
 OSM experiences : http://www.leretourdelautruche.com/map/


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

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


Re: [Tagging] seafood vs fishmonger (was Re: Synonymous values in the shop key)

2014-07-31 Thread Dan S
2014-07-31 11:02 GMT+01:00 Martin Koppenhoefer dieterdre...@gmail.com:


 Am 31/lug/2014 um 10:27 schrieb Holger Jeromin mailgm...@katur.de:

 The voting was performed using the extended North-American definition
 - there including fresh water:
 http://wiki.openstreetmap.org/wiki/Proposed_features/seafood_shop

 So i see no problem in tagging seafood for every dead fish.

 we are using British English, so this doesn't fit well

I appreciate that, but despite being a British English speaker I'm
happy with shop=seafood, and maybe we can use sub-tags to designate
variations on the theme. shop=seafood was porposed, voted and approved
4 years ago and is now more common than shop=fishmonger, so I'd
suggest we should make ourselves comfortable with it :)
http://taginfo.openstreetmap.org/compare/shop=seafood/shop=fishmonger/shop=fish

Dan

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


Re: [Tagging] How to tag road junction names and traffic signal names?

2014-07-24 Thread Dan S
If place=hamlet is wrong, I believe place=locality is often used as a
generic tag for nodes indicating named locations. Not really a
solution but a simple option.

Dan

2014-07-24 17:01 GMT+01:00 Lukas Sommer sommer...@gmail.com:
 Yes, I know that junction=yes works fine for simple crossroads. My question
 is: How should we map complex junctions like
 http://www.openstreetmap.org/node/2351057522#map=19/5.34399/-4.00300 Using
 just an unconnected node like in this example (even after removing the wrong
 place=hamlet tag) maybe is difficult for turn-to-turn navigation software.
 So, how can we solve this?

 Lukas Sommer


 2014-07-24 15:29 GMT+00:00 Christian Quest cqu...@openstreetmap.fr:

 Have you looked at http://wiki.openstreetmap.org/wiki/Key%3Ajunction

 junction=yes can be useful for a simple junction node that has a name=*
 tag

 I'm using that in the OSM-FR rendering... and even deal with
 traffic_signals icon shift to display both icon+name. ;)



 2014-07-24 16:42 GMT+02:00 Martin Koppenhoefer dieterdre...@gmail.com:


 2014-07-24 15:24 GMT+02:00 Lukas Sommer sommer...@gmail.com:

 Current situation:
 We have the tags highway=traffic_signals (for traffic signals on road
 junctions or at straight roads – typical for Japan) and junction=yes (for
 road junctions with or without traffic signals – typical for Ivory Coast) 
 in
 use at OSM. Both tags are almost exclusively used on nodes. They can be 
 used
 together with name=*. This works quite well for simple crossroads (example:
 http://wiki.openstreetmap.org/wiki/File:Junction_yes_example_1.png)

 Shortcomings of the current situation:
 It isn’t defined how to tag more complex cases.




 maybe the junction key can be used more universally (with different
 values), we are already using it also with junction=roundabout, only that it
 could be disputed that junction=roundabout is covering the whole junctions
 (the entries and exits you often have to a roundabout could be seen as part
 of the junction for instance). More in-use values can be found here:
 http://taginfo.openstreetmap.org/keys/junction#values
 Some of them maybe aren't junctions (what kind of junction is
 approach?), others are diverging from our standard mantra (no
 abbreviations), like spui or ddi and might merit retagging?

 cheers,
 Martin

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




 --
 Christian Quest - OpenStreetMap France

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



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


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


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

2014-07-23 Thread Dan S
Hi Dave,

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/
If you believe there's an issue then you can file an Issue on that
site. But the style is not really managed by community consensus
(praise be, since design-by-committee would make it even uglier than
it is ;) so don't expect a mass of discussion before every change.

Best
Dan

2014-07-23 22:59 GMT+01:00 Dave F. dave...@madasafish.com:
 Hi

 Change in rendering of Mapnik Nature Reserves.

 I probably missed the discussion for the above. Personally I like the
 previous incarnation with NR letters displaying. It was enough on its own to
 indicate a discernible area, but left enough space to infill with areas of
 grass/woods etc.

 Now, on its own, it looks bereft of clarity with just a faint dashed border
 line.

 What was the reasoning?

 Regards
 Dave F.

 ---
 This email is free from viruses and malware because avast! Antivirus
 protection is active.
 http://www.avast.com


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

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


Re: [Tagging] RFC: crossing=* (was: highway=speed_camera equivalent for non-speed enforcement types)

2014-07-22 Thread Dan S
2014-07-22 10:43 GMT+01:00 André Pirard a.pirard.pa...@gmail.com:

 On 2014-07-22 11:01, Jo wrote :
 I have mentioned without much follow-up a similar issue with highway=crossing 
 + crossing=*.
 What OSM calls crossing, zebra stripes, is in fact a passage pour piétons 
 which does not necessarily cross.

Why do you believe that OSM crossing refers not to a place where
highways may be crossed, but to any demarcated pedestrian area on a
highway? In british english it's very clear that a crossing is where
people cross. If passage pour piétons refers to a more general
category, then you need to be careful not to confuse the categories.

The wiki says (but not at the top) This tag is for the node at the
intersection of highways and footways. That matches my understanding
of it.
http://wiki.openstreetmap.org/wiki/Tag:highway%3Dcrossing

 In Belgium (too), we have quite a number of passages pour piétons painted 
 longitudinally and it makes sense.
 Children's safety, for example, is just as important if they have to walk 
 alongside on the road.
 Or it may be painted across a parking lot, in which case mapping 
 highway=crossing ways make sense.
 crossing=* alone (which, as a highway=* tag implicitly means 
 highway:crossing) is sufficient.

 So, I am proposing:

 to allow crossing=* on any highway=* when the painting is longitudinal
 crossing:right=yes, crossing:left=yes in that case
 highway=crossing for a way painted across an area

If crossing were to be used for places where you cannot cross, this
would confuse many people. I'd suggest you need to use a different
tag.

Best
Dan

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


Re: [Tagging] Synonymous values in the shop key

2014-07-10 Thread Dan S
Thanks for your work Mateusz!

2014-07-10 10:21 GMT+01:00 Martin Koppenhoefer dieterdre...@gmail.com:
 Am 10/lug/2014 um 11:19 schrieb Martin Koppenhoefer dieterdre...@gmail.com:

 I'd be careful with fishmonger vs seafood (is the latter OK for someone who 
 only sells fresh water fish?)

 also shop=fish might be used for pets (fish only)?

That is the only issue that makes me nervous about the suggested
josm-rules; shop=fish might indicate a pet shop in some cases.
Although since the rules are for josm validation so will be checked by
a human, I guess that's low-risk right?

Dan

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


Re: [Tagging] MyPlace self-storage facilities

2014-07-04 Thread Dan S
I notice there are also 209 amenity=storage:
http://taginfo.openstreetmap.org/compare/amenity=storage/shop=storage/shop=storage_units/shop=self_storage
Though I can't guarantee they refer to these self-storage places
(could be private storage if not shop?), some of the UK items
definitely are. And it feels kinda amenity-like...

Dan

2014-07-04 10:26 GMT+01:00 Andreas Labres l...@lab.at:
 Is there a clue how to tag such self-storage facilities (eg. MyPlace):

http://www.myplace.at/de/where_is_myplace/vienna/hietzing.html

 Taginfo finds:
 94shop=storage_units
 46shop=storage
 16shop=self_storage

 (plus some typos/uppercase/withspace)

 /al

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

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


Re: [Tagging] Where do source tags belong?

2014-06-26 Thread Dan S
2014-06-26 12:44 GMT+01:00 André Pirard a.pirard.pa...@gmail.com:

  Hi,  I wonder if this phrase without an explanation link
 http://wiki.openstreetmap.org/wiki/Key:source contains appropriate
 instructions (or just press news):

 *Since the introduction of changesets these tags are often added as
 changeset http://wiki.openstreetmap.org/wiki/Changeset tags rather than
 in the features themselves.*

 It sounds like (rather than) source tags in objects must now be replaced
 by source tags in changesets.


Hi Andre,

The sentence says changeset tags are often used in preference, and in
your restatement you have converted often to must now be replaced by.
That is a massive difference, and I feel you've misread. I think the
sentence in the wiki strikes the correct balance.



 While doing so may be appropriate to for huge bulk imports, I don't think
 it's always, even generally, the case.


I agree.



 Suppose an osm file built from version 2014_04 of BusCo bus stops data.
 The OSM contributors are invited to copy each object to OSM and to check
 the data, esp. coordinates.
 Should:

- this file's objects contain source=BusCo 2014-04 (ISO date)
 - or the contributor be requested to add that tag to the changesets
for each and every update

 In the first case, the tagging will be done without mistakes and the
 source will be very apparent on the main OSM Web map not only for the
 reader to see but also for overpass to filter which data belongs to BusCo
 and even which is not yet at the latest update.

 In the mistake prone, second case, the mapper will be asked to force
 himself in different updates for BusCo and for other necessary updates that
 he will inevitably meet in the process, and the net result of that hassle
 will be a misplaced source tag with regard to visibility and overpass.

 Which is the best method? Or is there another one?

I personally would say that your changeset source tags should only list the
sources that have been used to make the changes you have made. In other
words, your option 2 shouldn't be recommended. In the case you give, I
would recommend to leave object source tags as they are, and add changeset
tags listing any extra sources that the contributor used for their changes.
I know this feels odd because the total source of the OSM data ends up
split between object and changeset, but I think it's acceptable way to
progress, and it definitely remains possible for a machine ot calculate the
total sources list.

 I think that changeset source tagging is only appropriate to mechanical
 imports and that the above phrase should say so or link to some reading
 that does.


I disagree. When I do edits using a single source, it makes a lot of sense
to put the source tag on the changeset. When I do edits using multiple
sources, it makes a lot of sense to put the source tags on the objects.



 It seems strange to have to split updates one per object so that the
 correct source tags are present on each when they could equivalently and
 more appropriately be on the object itself.
 Typical, compared to the variety of object source tags format, is this
 scarce instruction in changeset
 http://wiki.openstreetmap.org/wiki/Changeset:


- source http://wiki.openstreetmap.org/wiki/Key:source=* – specify
the source for a group of edits

  Typically, source for does not say source of what.  Of the objects or
 of the edits as a whole import?


Good spot. So the text needs improving. I've edited the sentence to try and
improve it. Obviously I've edited it using my own understanding of the
consensus idea of the tag, so if I'm wrong let's just keep improving it :)

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


Re: [Tagging] No abbreviations in names edge case

2014-06-18 Thread Dan S
2014-06-18 15:35 GMT+02:00 Richard Welty rwe...@averillpark.net:
 On 6/18/14 8:28 AM, Florian Schäfer wrote:
 What about the homepage of the city [1]? There it says that The actual
 name comes from the fact that our town site on a strip of Cherokee land
 famous for the Oklahoma Land Run. The name stands for *Indian Exchange
 Land*.
 in this case, i'd argue that the abbreviation is the name
 and you could use note= or something like that to note
 the origin of the name.
 richard

I'd suggest

name=IXL
old_name=Indian Exchange Land

Great edge case :)

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


Re: [Tagging] Signal-controlled roundabouts

2014-06-13 Thread Dan S
Roundabouts like this sometimes (in Britain) have part time traffic
lights. So, some times of day it is a true roundabout, and some times
of day it is a circle of road with traffic signals! I don't know the
one you linked, to but it's possible that is what is going on here.

Dan

2014-06-13 16:54 GMT+01:00 Fernando Trebien fernando.treb...@gmail.com:
 Hello,

 I used to believe that, by definition, all roundabouts have free
 transit and right of way along the circle, and that anything that
 didn't display that property isn't a roundabout (just a circle). But
 reading the wiki once again, I'm a little in doubt. The wiki mentions
 that this is a roundabout, but I would previously have thought it
 wasn't because of the traffic lights within it:
 http://www.openstreetmap.org/#map=19/52.59689/-1.14146

 So why is it a roundabout? Is it because of the circular shape? Or
 could it be because it's impossible to infer that any of the entering
 ways have right of way, since they are all controlled by traffic
 lights?

 --
 Fernando Trebien
 +55 (51) 9962-5409

 Nullius in verba.

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

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


Re: [Tagging] turning layers off

2014-06-05 Thread Dan S
(not a tagging question really, but)

Top tip: Ctrl-W in JOSM (wireframe mode) makes areas show as
outlines rather than tinted areas.

Dan


2014-06-05 15:50 GMT+01:00 Matthijs Melissen i...@matthijsmelissen.nl:
 Yes, in JOSM, you can use the Filters window.

 -- Matthijs

 On 5 June 2014 15:46, Tom Gertin tger...@gmail.com wrote:
 Is it possible to turn visibility of certain layers or feature types off in
 OpenStreetMap (Id or JOSM), such as features with a landuse tag?

 I am having a hard time drawing building polygons inside landuse polygons
 because the landuse polygons have a colored tint to them.

 Thanks,

 Tom G.

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


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

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


Re: [Tagging] Wiki edits, building tags on nodes versus areas

2014-06-04 Thread Dan S
2014-06-04 18:03 GMT+01:00 bulwersator bulwersa...@zoho.com:
 I guess that push toward tagging POI as nodes is result of fact that in some
 situations only nodes are processed properly (at least that is why I tag new
 features in this way).

I don't think it's a good idea to adapt your tagging practices to suit
systems that can't be bothered to handle ways/relations! Please, if
you think a feature is geographically better represented as a way, do
it as a way.

I prefer to map the physical extent of a shop when possible, since
shops very often occupy a non-trivial physical area (especially large
ones, e.g. supermarkets).

So to answer the original question: no those wiki edits would seem to
be misguided, and for more reasons than just one-feature-one-element.

Just my 2p of course

Best wishes
Dan


  On Wed, 04 Jun 2014 09:43:25 -0700 Andrew Hain
 andrewhain...@hotmail.co.uk wrote 

 Over the past few days there have been a number of wiki edits (mainly but
 not entirely in German) stating that shop=* and similar tags, contrary to
 the “One feature, one OSM element” principle [1], should only ever be put
 on nodes and not on building polygons. I’ve commented on an affected talk
 page without any response.

 Is there any justification for these edits?

 [1] http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element



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



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


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


Re: [Tagging] cleanup broken import fix

2014-05-28 Thread Dan S
If I understand right you should probably ask imports@ not tagging@
about making bulk edits, even if they're to fix bulk edits!

Best
Dan


2014-05-28 21:53 GMT+01:00 malenki o...@malenki.ch:
 Recently I found some 10.000 (one of two changesets contained 38k)
 objects tagged like this:¹
 | gnis:fcode=39004
 | natural=water
 | nhd:com_id=146082168
 | nhd:fdate=Mon Mar 06 00:00:00 PST 2006
 | nhd:reach_code=18030012024071
 | source=NHD
 | water=lake;pond

 They were imported by nmixter and in v1 were tagged like this:
 | ele=0.0
 | gnis:fcode=39004
 | gnis:ftype=LakePond
 | natural=water
 | nhd:com_id=146082168
 | nhd:fdate=Mon Mar 06 00:00:00 PST 2006
 | nhd:reach_code=18030012024071
 | source=NHD

 WorstFixer removed ele 0.0 and honoured his name by converting
 gnis:ftype=LakePond to
 water=lake;pond

 Has anyone objections for removing water=lake;pond and also the other
 proprietary data?
 I'd think
 | natural=water
 and
 | source=NHD
 (and in case it is there)
 intermittent=yes
 should be sufficient

 See also: https://github.com/openstreetmap/iD/issues/2237

 Regards
 Thomas

 ¹ example: https://www.osm.org/way/73966050/history

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

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


Re: [Tagging] [OSM-talk] boules=petanque vs. type=petanque

2014-05-15 Thread Dan S
2014-05-15 10:00 GMT+01:00 Jean-Marc Liotier j...@liotier.org:
 Well... Private messages tell me that boules might be popular outside of
 France, so here is a translation for a more international debate...

 According to http://wiki.openstreetmap.org/wiki/Tag:sport%3Dboules a
 petanque pitch (leisure=pitch) is:
 sport=boules
 boules=petanque
 (375 nodes, 75 ways - http://overpass-turbo.eu/s/3op)

 But according to http://wiki.openstreetmap.org/wiki/FR:Key:sport it is:
 sport=boules
 type=petanque
 (607 nodes, 111 ways - http://overpass-turbo.eu/s/3oo)

 Any opinions on a future harmonization of the tagging of boules game types ?

type is far too vague - it doesn't namespace at all, so it doesn't
make it definite if it's a type of boules, a type of pitch, etc. The
english wiki says, and I concur, Key:type should be avoided:
http://wiki.openstreetmap.org/wiki/Key:type
Much better to standardise on the chaining approach i.e. boules=*
(or boules:type=* would have been another possibility in a parallel
universe). Luckily, the number of petanque objects is small enough
that it's possible to harmonise, so long as the nations can agree :)

Just my 2p
Dan

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


Re: [Tagging] access=designated - what do we think it means?

2014-04-11 Thread Dan S
2014-04-11 18:20 GMT+01:00 Pieren pier...@gmail.com:
 On Fri, Apr 11, 2014 at 7:07 PM, Tod Fitch t...@fitchdesign.com wrote:

 (2) http://wiki.openstreetmap.org/wiki/Tag%3Aaccess%3Ddesignated

 This is how I understood and have used it.


 This is what the wiki says:
 Note that access=designated is not defining what is designated and is
 meaningless. 

Please, before quoting the wiki in a tagging discussion, check if your
choice quote was added two hours ago as a direct result of this
tagging discussion! Quoting that particular sentence from the wiki is
almost exactly equivalent to quoting an email message in this thread.

Dan

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


Re: [Tagging] access=designated - what do we think it means?

2014-04-11 Thread Dan S
2014-04-11 19:14 GMT+01:00 Vincent Pottier vpott...@gmail.com:
 Le 11/04/2014 19:38, Dan S a écrit :

 2014-04-11 18:20 GMT+01:00 Pieren pier...@gmail.com:

 On Fri, Apr 11, 2014 at 7:07 PM, Tod Fitch t...@fitchdesign.com wrote:

 (2) http://wiki.openstreetmap.org/wiki/Tag%3Aaccess%3Ddesignated

 This is how I understood and have used it.


 This is what the wiki says:
 Note that access=designated is not defining what is designated and is
 meaningless. 

 Please, before quoting the wiki in a tagging discussion, check if your
 choice quote was added two hours ago as a direct result of this
 tagging discussion! Quoting that particular sentence from the wiki is
 almost exactly equivalent to quoting an email message in this thread.

 Dan

 It seems that January 24th 15h40 is a little older than 2 hours.
 And quotting this sentence in the wiki is not exaclty quotting this thread.

Oh my apologies! I clearly misread the date. Sorry for adding
confusion to the confusion!

Dan

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


Re: [Tagging] Ticket for JOSM to read contact metadata closed

2014-04-02 Thread Dan S
2014-04-02 18:25 GMT+01:00 Andy Mabbett a...@pigsonthewing.org.uk:
 Not only was I disappointed to see this ticket:

http://josm.openstreetmap.de/ticket/9885

 closed as wontfix, but I don't understand the reason given:

This format seems not to be used much.
Too much work for too little gain.

 not least since I specifically referred to an hCard microformat or
 some other contact metadata.

 Was I unclear in my proposal?

No, it was clear. However, when I read the ticket, my first thought
was, That would be ideal for a josm plugin, and I don't see why
anyone would propose it for core josm rather than a plugin. I didn't
want to say it out loud and pre-empt decisions of actual josm
developers.

I know how those microformats work but I don't feel that they're very
common, so I don't have any particular problem with the reason given.
Do you feel to the contrary, that they are used much? Do many
business/organisation websites actually add these things?

Best
Dan

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


Re: [Tagging] Issues relating to URIs and tagging

2014-04-01 Thread Dan S
Hi Andy,

2014-04-01 16:29 GMT+01:00 Andy Mabbett a...@pigsonthewing.org.uk:
 Hello everyone,

 This is my first post to the list, which I've just joined, but I've
 been a mapper for a few years and some of you might remember me as
 compere at last year's State of the Map.

And well done indeed!

 Yesterday, I met with the W3Cs'  data on the web best practice
 working group. At their request, I gave a talk on the use of URIs
 (particularly linked data URIs) and related tags,  in OSM.

 I described, and we then discussed, how we tag entities in OSM, using
 UIDs but not necessarily URLs, and issues facing data users who need
 to resolve those UIDs back to URLs; for example:

 openplaques_plaque = 1536

 to:

http://openplaques.org/plaques/1536

 To that end, I've just modified [[Template:KeyDescription]] by adding
 two parameters:


 https://wiki.openstreetmap.org/w/index.php?title=Talk:Tag:historic%3Dmemorialdiff=prevoldid=1010411

 for website and url_pattern

That URL doesn't seem right. I think you mean
https://wiki.openstreetmap.org/w/index.php?title=Template%3AKeyDescriptiondiff=1010399oldid=1009143

 see:

https://wiki.openstreetmap.org/wiki/Key:openplaques_plaque

 of an example of how they're intended to be used (the label display
 needs tweaking).

Tell me if I've misunderstood you, but you're proposing that the
url_pattern given in the wiki infobox KeyDescription is intended to
be machine-readable, in the sense that a third-party data consumer can
plug url_pattern together with the actual key-values found in OSM and
automatically find the URL for something? If so, the idea is
intriguing and I think it's a nice lightweight thing we can do.

I have a small quibble which is please change it from URL to URI,
since I think the latter is the more appropriate concept. We're aiming
to interlink _identities_ of items really, for the machines.

 The model used there fails with Wikipedia links,
 expressed as en:Example, because the equivalent URL is
 https://en.wikipedia.org/wiki/Example. Any suggestions for dealing
 with that?

I don't see a plausible way of dealing with this that wouldn't be a
crazy hack. So I'd recommend that data re-users will simply need to
treat this as a special case if it's important to them. (I've always
thought the wikipedia tag would have worked better as
wikipedia:en=Example -- in that case, your template approach would
have worked fine.)

 They were very impressed with the inclusion of Wikidata IDs

https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Wikidata

 The sooner we move that from Talk:Proposed_features/ to Key:, the better.

Wikidata proposal looks good to me.

 Other issues which are unhelpful to data re-users include keys with
 missing documentation; redundant keys (Key:openplaques_plaque vs
 Key:openplaques_id);

I have never seen these tags, but there are very few uses - this
example is probably really easy to consolidate into one tag.

The harder cases will - as discussed in recent threads on this list -
will remain in a state of productive controversy for a long time to
come! Sorry, data re-users, but that's wiki-life for you.

 ambiguous keys (ref=1234 - ref in whose database?)

That's an interesting question. ref is widely used, and generally
used quite coherently, _but_ its meaning is contextual on other tags.
For example, amenity=post_box  operator=Royal Mail tells you
where to expect the ref to point. I wonder if operator sets the
context in many other cases? (I accept, of course, that many objects
aren't tagged with operator.)

 and the perennial problem of the lack of stable URIs for entities in OSM. I 
 have yet to solve that one...

OSM objects are not stable, same as Wikipedia articles. For Wikipedia
they provide partial stability through long-term historical oldid
links and redirects. I don't think tagging (i.e. this list) can solve
the permalink problem. It needs osm.org to provide a URL scheme that
allows people to link to a specific historical _version_ of an osm
object. We already provide direct links to changesets and to object
histories, so the data is all there.

Best
Dan

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


Re: [Tagging] Feature Proposal - RFC - Wikidata

2014-04-01 Thread Dan S
2014-04-01 22:17 GMT+01:00 Tobias Knerr o...@tobias-knerr.de:
 On 01.04.2014 19:04, Andy Mabbett wrote:
 I commend this proposal to the list:

https://wiki.openstreetmap.org/wiki/Proposed_features/Wikidata

 I like Wikidata and therefore want to see this proposal approved. :)

 What I'm interested in, though: If an object exists both in Wikipedia
 and Wikidata, would you expect both tags to be used? Wikipedia links can
 be obtained from the Wikidata API for a given Wikidata ID and vice
 versa, so one of the two would suffice.

Long-term, it seems possible that wikidata might end up as the primary
way to make these cross-reference connections, but that depends on the
future evolution of both osm and of wikidata. Short- and medium-term,
existing wikipedia tagging is not going to be deprecated or
automatically replaced, services will probably continue to make use of
it, and it has some advantages (such as readability). I don't think we
should expect both to be used, but it should be no problem if both
are applied to a particular object.

Dan

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


Re: [Tagging] What is OSM: a base layer for individual maps, or a fully featured geobased information system?

2014-03-29 Thread Dan S
Hi -

I'm afraid the answer is neither. OSM is a database for geodata that
is open-licensed, publicly verifiable and not short-term. This means
it's more than just a base-layer. But it also means it's not a
database for all possible geodata. We don't include holiday apartment
reviews/ratings because they're too subjective; we don't include the
local temperature because it changes too quickly.

You're going to have to live with the fact that (a) no-one wants to
render your tag until it has some momentum, while (b) rendering
certainly helps a tag get momentum, but that doesn't mean that your
tag deserves that benefit yet. Much better is if you start using
your tag, and then maybe the community of boat-sharing users starts to
use it too, and maybe renders a special boat-sharing map, and the
tagging develops organically. It doesn't make a big difference whether
it's been officially voted in or not.

There will always be geodata that doesn't belong in OSM, such as house
prices, tripadvisor ratings, crime rates. OSM doesn't need to ingest
this data in order to be useful; it needs to be available to get
mashed-up with this data.

Best
Dan


2014-03-29 12:41 GMT+00:00 nounours77 kuessemondtaegl...@gmail.com:
 Hi there,

 Not sure if this is the right place for this philosophical question. But
 starting from the comment of Brycenesbitt to my apartment-proposal I feel
 this will become yet another piece of unmaintanable data in OSM. and
 several comments I got on my boat_sharing proposal just use it, don't go
 through proposal process I think it's a important question. What do we
 define tags for?

 A) OSM is just a base layer
 We tag just for general features of the landscape, and maybe roads. This
 will make a beautiful map, which then can be used as a base layer, e.g. for
 a holiday-apartment renting agency, which than can render all there
 apartments from their own private database as an overlay on OSM base layer.
 = this will mean, we do not have to maintain the apartment info, nor has
 the provider to bother with OSM. This is much easier. But means that the
 information is only avaible on the agencies website, and thus there will be
 million places I have to look for the info.

 B) OSM as a fully featured geobased information system
 We see of OSM a a standalone, fully featured geobased information system. I
 can take the map in my pocket (like on the iPhone App PocketEarth, or
 OsmAnd), and will everywhere have any kind of information. I'm driving
 through a village, I like it, and I want to stay. So, where are the next
 nice holiday-apartments around me?
 Of course, this only works, if the data is maintained and current. But: I
 want OSM to get important enough that every service provider offering a
 service to a wide enough public is just forced in his own interest to
 publish it's data on OSM and keep it current.

 As a conclusion for us this means: Yes, we need a defined tagging (accepted
 proposal) for tourism=apartment, ifnot, never ever all service providers
 will put their apartment on OSM. And never the Apps like PocketEarth or
 OsmAnd will support to render it.
 I was advised by several persons that I should just use
 tourism=boat_sharing, and not bother about going through a proposal and
 voting process. BUT: I asked OsmAnd to render the tag, and the answer was -
 quite understandable: Only officially supported tags will be rendered.
 There we are again with the well know snake which bites it's tail: No data -
 no rendering. No rendering, nobody collects data or publishes it on OSM.
 My answer to this would be: make a reasonable, understandable, clear and
 clean tagging scheme, discuss it, vote it, document it. If done properly,
 the data will come and the rendering as well.

 Please, what is your vision of OSM? A or B?

 If A, I will stop bothering about tourism=apartment, amenity=boat_sharing,
 or amenity=nursery, since this are all service informations you can argue
 you can find somewhere else ...
 But if it's B), then we need all that to make OSM the best, most complete
 and inevitable geobased information system.

 Thanks for your comments, and yes, I reopened the boat_sharing proposal for
 voting, just in case somebody wants to support me!!!

 Have a nice week-end,

 Nounours77

 https://wiki.openstreetmap.org/wiki/Proposed_features/boat_sharing
 https://wiki.openstreetmap.org/wiki/Proposed_features/apartment


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


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


Re: [Tagging] Fixing wrong opening_hours automatically

2014-03-07 Thread Dan S
2014-03-06 17:13 GMT+00:00 Robin `ypid` Schneider ypi...@aol.de:
 On 06.03.2014 10:47, Martin Koppenhoefer wrote:
 2014-03-05 21:25 GMT+01:00 Robin `ypid` Schneider ypi...@aol.de:

 There is no key öffnungszeiten, but yes it is only about the key
 opening_hours.
 As said before I am not going to change the meaning. The value 'nach
 Vereinbarung' is used more often so that's another reason for that.



 I am generally opposing german language values in formalized tags *),
 especially where a generic fact is expressed that has a corresponding word
 in English like here. For this reason I am opposing that you normalize
 those tags as it would distort the actual tagging numbers and next time
 you'd be able to say that there are even more of these values, all unified
 in the same clean format ;-)

 In general I agree with you. But I see the comment in opening_hours more like
 the description key which can (or should) be in local language.

I'm sorry but if it is description-like, then it is free text and
shouldn't be auto-standardised in the manner you propose. You need to
decide if you think it is description-like (== free text, local
language) or formalised (==set of possible labels, british english).

Dan

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


Re: [Tagging] Hot springs

2014-03-03 Thread Dan S
2014-03-03 12:53 GMT+00:00 nounours77 kuessemondtaegl...@gmail.com:

 I have significantly changed 
 https://wiki.openstreetmap.org/wiki/Proposed_features/Hot_Spring
 with the intention to revive the proposal - thanks for any comments and 
 enhancments.


 Dear Richard,

 thanks for your initiative. I agree with your arguments why a specific tag 
 natural=hot_spring is better than natural=spring and temp=*. It is 
 something different.

 Not sure about the word consistence which looks strange to me (but I'm not 
 native).

consistence is not standard English. You probably don't mean
consistency either. content?

Dan

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


Re: [Tagging] Fwd: tag for planetarium

2014-02-25 Thread Dan S
Hi all,

Well amenity=* has been something of a default choice in the past, so
the definition is quite stretched from community facilities as the
wiki puts it. There are some well-established tags that might be
better as leisure=* or tourism=* if we were starting from scratch. So
I'd suggest tourism=planetarium might be the best choice; but all of
the suggestions are fine really!

Dan


2014-02-25 0:28 GMT+00:00 Dave Swarthout daveswarth...@gmail.com:
 I think amenity=planetarium is perfectly reasonable. A planetarium is a
 place that resembles a theater but the show involves models of the planets
 and/or the stars  universe. If OSM can have an amenity=brothel tag, we can
 certainly have an amenity tag for planetaria, which are in my opinion
 something for the benefit/enjoyment of society as a whole whereas it is
 arguable whether brothels fit into that category. ;-)


 On Tue, Feb 25, 2014 at 5:27 AM, John Packer john.pack...@gmail.com wrote:

 Perhaps instead of amenity=*, it should be added to tourism=*.

 It seems that's where the discussion is going to.


 2014-02-24 19:23 GMT-03:00 Richard Welty rwe...@averillpark.net:

 On 2/24/14 5:17 PM, Colin Smale wrote:
 
 
  I would not call it an amenity, which is (to me, native UK English
  speaker) something for the benefit/enjoyment of society as a whole (or
  at least a large part of it). These days a planetarium is probably for
  enjoyment/entertainment (suggesting leisure=planetarium).

 on the other hand, in my experience Planetariums are usually
 attached to museums of one kind or another, whether science
 museums or children's museums.

 richard
 --
 rwe...@averillpark.net
  Averill Park Networking - GIS  IT Consulting
  OpenStreetMap - PostgreSQL - Linux
  Java - Web Applications - Search


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



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




 --
 Dave Swarthout
 Homer, Alaska
 Chiang Mai, Thailand
 Travel Blog at http://dswarthout.blogspot.com

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


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


Re: [Tagging] How to tag a public works facility ?

2014-02-19 Thread Dan S
Hi -

In the past I've seen people use landuse=depot
http://wiki.openstreetmap.org/wiki/Tag:landuse%3Ddepot

Dan


2014-02-19 9:06 GMT+00:00 Pieren pier...@gmail.com:
 It's a small area with several buildings where the municipality is
 storing vehicles and the maintenance and repair services. Someone
 suggests to use amenity=public_building but it's deprecated now in
 the wiki... building=public doesn't fit well here because it's an
 area and is not open to the public.
 Something new like amenity=public_works ? (0 in taginfo)

 Pieren

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

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


Re: [Tagging] Architectural Monuments - ideas?

2014-02-17 Thread Dan S
2014-02-17 12:58 GMT+00:00 nounours77 kuessemondtaegl...@gmail.com:
 Dear Clifford, dear Pierren,

 thanks for your thoughts. Here some answers


 What/Who defines what is an Architectural Monument? When I think it is more
 along the lines of what Wikipedia [1] defines as a monument.

 No, I'm not (specifically) talking about specific monuments created for 
 commemoration purpose.

 What I think
 of as a building designed by famous architects,  it is more along the lines
 of a Frank Gehry building. i.e. The  Guggenheim
 Museum

 Yes, this I have in mind, and even less important.

 Can you clarify your proposal to help me better understand. (Pics would be
 great.)

 Find 2 examples from the Basel-list under [1] and [2]

 Also, do you mean an actual import? If so, please make sure the list is
 licensed appropriately for OSM and you discuss on the import mailing list.

 Yes, I'm talking about a specific import. It's part of the import of the 
 geodata of the State of Basel. Yes, we have explicit right to do so in 
 written from the government authority [3]. No, I did not intend to discuss it 
 on the import mailing list, since it's a very local import, I discussed it on 
 the swiss-talk only.

I'm not going to jump on this but you will very likely be frowned upon
for not mentioning it to the imports list.

 Pieren:

 More seriously, is it not something very subjective ? is OSM the right
 place for such list ? At least, heritage [1] is based on something
 verifiable [2].

 Yes, it is subjectively what is relevant enough to be tagged in OSM.
 The current list is a bit less subjective, since it's the official government 
 list of the state of Basel which enumerates 36 buildings as being of 
 architectural interest. Is this verifiable enough?

Ah! This official listing sounds much better, to me. You could perhaps
use listed_status as we do in the UK, if that is appropriate:
http://wiki.openstreetmap.org/wiki/Key:listed_status

 Thinking of it, a solution might be to just create Wikipediapages for all of 
 the 36 buildings (most are probably already there), and then set the 
 wikipedia tag to the building? But would that no remove information, since 
 there are so many wikipedia-tags, how can I get a map of all architectural 
 monuments in a city?

You would need to combine the two datasets. One way of doing this is
via linked-data: dbpedia (which gives you data from wikipedia
about-boxes, and linkedgeodata which gives you OSM.
http://dbpedia.org/
http://linkedgeodata.org/

Dan

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


Re: [Tagging] feature Proposal - RFC 2 - tourism = apartment

2014-02-16 Thread Dan S
2014-02-16 8:29 GMT+00:00 Philip Barnes p...@trigpoint.me.uk:
 On Sun, 2014-02-16 at 07:06 +0700, Dave Swarthout wrote:
 I would prefer the plural tourism=apartments.


 I prefer singular because the plural term explicitly states that more
 than one unit is available to rent while the singular implies only
 that there is at least one unit for rent on a short term basis.
 Therefore the plural designation might often be wrong while the
 singular will not.

 +1
 The plural also implies that all of the apartments in the building are
 available for short term holiday rental, whereas in reality there is
 likely to be a mix of rental and residential apartments in the building.

 Phil (trigpoint)

FWIW, I too am happy with the singular tourism=apartment.

I'll repeat what I said on the talk page: beds=* would be better as
capacity=*. Otherwise, looks OK to me.

Best
Dan

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


Re: [Tagging] How to map holiday flats? New tag tourism=holiday_flat or extend existing tourism=chalet

2014-01-06 Thread Dan S
Sounds good to me too, nice and simple :)

Dan

2014/1/6 Dave Swarthout daveswarth...@gmail.com:
 Personally I would go with tourism=apartment or apartments.
 +1

 On Mon, Jan 6, 2014 at 5:02 PM, Martin Koppenhoefer dieterdre...@gmail.com
 wrote:



  Am 05/gen/2014 um 17:44 schrieb Dudley Ibbett
  dudleyibb...@hotmail.com:
 
  Personally I would go with tourism=apartment or apartments.

 +1, thought this was already established practice.

 cheers,
 Martin

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




 --
 Dave Swarthout
 Homer, Alaska
 Chiang Mai, Thailand
 Travel Blog at http://dswarthout.blogspot.com

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


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


Re: [Tagging] How to map holiday flats? New tag tourism=holiday_flat or extend existing tourism=chalet

2014-01-03 Thread Dan S
2014/1/3 Richard Welty rwe...@averillpark.net:
 On 1/2/14 8:31 PM, Dave Swarthout wrote:
 I think of the word flat as being distinctly British. I have only
 rarely heard the word flat used to describe and apartment in the
 U.S. When I first glanced at the beginning of this thread I thought
 the OP was referring to flats of flowers. LOL
 flat was once much more commonly used in the US.

 and since OSM tends towards UK English usage, i think it's
 perfectly reasonable for OSM to use the term.

Reasonable, but since both flat and apartment may be vulnerable to
some international confusion, it's worth bearing that in mind.

We already have good tagging for building types, so it seems to me
there's no particular need to use the tourism=* tag to indicate
whether the accommodation is a free-standing chalet or a flat. If I
were starting from scratch, I might advocate tourism=self_catering.
But tourism=chalet is very close in meaning (except for the
implication that it's a free-standing building!) so I wonder if we can
simply use that existing tag, and let the building=* tags help us
decide if we want to spend our holiday in a free-standing structure!

I'd suggest that adding tourism=holiday_flat as well as tourism=chalet
is compounding an existing problem, making it so we have two tags
rather than one which unhelpfully merge building-type information and
primary-use information. I'd really like to suggest either modifying
the definition of tourism=chalet so it's more inclusive, or using
something like tourism=self_catering.

Best
Dan

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


Re: [Tagging] Feature Proposal - RFC - trafficability

2014-01-03 Thread Dan S
Hi,

It reminds me quite a lot of opening_hours
http://wiki.openstreetmap.org/wiki/Key:opening_hours
Would that be appropriate?

Dan


2014/1/3 BGNO BGNO bgno2...@gmail.com

 Hi,

 I am proposing a new key: 
 http://wiki.openstreetmap.org/wiki/Proposed_features/trafficability

 Cheers

 BGNO

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


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


Re: [Tagging] how to tag a terrace?

2013-12-13 Thread Dan S
2013/12/13 Martin Koppenhoefer dieterdre...@gmail.com:


 Am 13/dic/2013 um 13:37 schrieb Fabrizio Carrai fabrizio.car...@gmail.com:

 The final results is [1] a multypoligon the includes few components,
 including:

 A highway=pedestrian area, with black and white tiles marked as
 surface=paving_stones (that's the one with the terrace's balustrades)
 An acquarium [4]
 Grass areas
 A gazebo construction

 For this reason I would not mark it as terrace and definitively not
 building.

 The multipolygon is fine, it just lacks tagging ;-)

 The only tags that characterize it right now are the name and Wikipedia tag,
 there is no osm tag to say what it is.

highway=pedestrian area, with [...] surface=paving_stones seems to
tag it pretty well to me.

Note that may be a translation issue. In english the word terrace
used in this context basically just refers to the pedestrian area...
https://en.wikipedia.org/wiki/Terrace_%28building%29

 IMHO building would fit, what are the alternatives? man_made and historic,
 but historic would exclude similar constructions of recent make. Man_made is
 usually for more technical stuff, and in the past we used building even for
 ships (that don't move any more, with a restaurant inside).

building doesn't make sense to me. It is built in the sense of being
man-made or architectural, but then so is a bridge, a fountain,
etc.

Perhaps you could say what _aspect_ of the terrace you consider is not
reflected in the tagging that Fabrizio describes? The photo you
originally linked to shows a large and decorative pedestrian area,
which is not difficult to map. The multipolygon collects together the
geographic features that people presumably think of when they think of
the name Terrazza Mascagni. So, if those things don't satisfy you,
there must be some additional _quality_ that you have in mind?

Best
Dan

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


Re: [Tagging] how to tag a terrace?

2013-12-13 Thread Dan S
2013/12/13 Martin Koppenhoefer dieterdre...@gmail.com:

 2013/12/13 Dan S danstowell+...@gmail.com

 highway=pedestrian area, with [...] surface=paving_stones seems to
 tag it pretty well to me.



 those tags aren't on the relation that represents the whole object though.




  IMHO building would fit, what are the alternatives? man_made and
  historic,
  but historic would exclude similar constructions of recent make.
  Man_made is
  usually for more technical stuff, and in the past we used building even
  for
  ships (that don't move any more, with a restaurant inside).

 building doesn't make sense to me. It is built in the sense of being
 man-made or architectural, but then so is a bridge, a fountain,
 etc.



 yes, as we don't have a tag for bridges either (all we use is an attribute
 to a railway or highway that it is on a bridge, we don't actually map the
 bridge itself, besides the bridge relation maybe), a building=bridge is fine
 for me as well.

 Perhaps you could say what _aspect_ of the terrace you consider is not
 reflected in the tagging that Fabrizio describes?

 Actually it was himself who described that the terrace consists of several
 parts:

 A highway=pedestrian area, with black and white tiles marked as
 surface=paving_stones (that's the one with the terrace's balustrades)
 An acquarium [4]
 Grass areas
 A gazebo construction

 The photo you
 originally linked to shows a large and decorative pedestrian area,
 which is not difficult to map.

 it is not just a pedestrian area, it is also retaining walls, ceiling, a
 pavillon, stairs, foundations, ...
 http://img76.imageshack.us/img76/474/terrazzamascagniwj9.jpg


 The multipolygon collects together the
 geographic features that people presumably think of when they think of
 the name Terrazza Mascagni. So, if those things don't satisfy you,
 there must be some additional _quality_ that you have in mind?

 I think that there is clearly an object  which is called terrazza xy
 which consists of several parts, which is a built structure, and which is
 more than just a pedestrian area. I think that who created the multipolygon
 relation thought the same (hence he created the relation and attached the
 name and wikipedia link to it).

I know you think it's clear, but it isn't clear to me what the edges
of this object might be, which is why I asked you if you could say
some more about this. If I understand you right, maybe one of the
closest parallels in OSM tagging would be leisure=park? I'm not
suggesting you should use this tag, just that maybe the object you
have in mind has a similar ontological status. For example it's weird
to me to think that grass areas or other buildings (mentioned above)
would be considered a sub-part of a building=* object. But, for
example, it's quite common for leisure=park objects to have grass
areas and buildings inside.

Dan

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


Re: [Tagging] Topographic place names

2013-12-10 Thread Dan S
2013/12/10 Andrew Errington erringt...@gmail.com:
 On Tue, 10 Dec 2013 19:26:55 Steve Bennett wrote:
 Hi all,
   My cycletouring map, http://cycletour.org, has been slowly morphing into
 a general topographic map[1]. One thing that's missing, though, is names
 for topographic features like mountain ranges, spurs, and general areas.

 Looking at http://wiki.openstreetmap.org/wiki/Category:En:Key:natural,
 there seem to be some gaps.

 - how do you tag a mountain range? That is, not a single ridge or mountain,
 but a line of mountains, potentially hundreds or even thousands of
 kilometres long
 - how do you tag a spur? In Australia, many spurs are named, (Champion
 spur, Son of a bitch spur). natural=ridge perhaps?
 - how do you name a generic geographic feature, like a cluster of rocks
 (Mushroom rocks) or a vague features like the blowhole, something
 hollow. The tags are all very specific and seem to imply the ability to
 render it somehow other than using words. (I have ended up using
 place=locality for some of these but it doesn't seem right.)

 Steve
 [1] See this area for instance: http://bit.ly/1gVmycD


 Yes please!  I just added some hiking trails and had a named spur[1] that I
 wanted to record.  I used place=locality, but it seems wrong for the same
 reasons you give.  I'd suggest that since we have natural=peak, and
 natural=saddle we should have natural=spur.  natural=ridge, if it's not
 already used, should be for ridges.  Perhaps we could also have
 natural=feature for a general named 'thing' that is visible and well known.
 Could be any sort of rock, outcrop, fissure etc.

All sounds good. Note that for rocks and outcrops we do have tags:
http://wiki.openstreetmap.org/wiki/Tag:natural%3Dbare_rock
(I was using natural=rock before but it seems natural=bare_rock is
preferred since less ambiguous. I tend to use this for standing rock
areas as well as for flat ones...)

Dan


 [1] http://www.openstreetmap.org/#map=15/35.7236/128.0624layers=C

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


Re: [Tagging] Mechanical edit - Voting - Musical instrument (reminder)

2013-12-09 Thread Dan S
2013/12/9 Martin Koppenhoefer dieterdre...@gmail.com:

 2013/12/9 Matthijs Melissen i...@matthijsmelissen.nl

 Just to keep you up-to-date: the data working group has not responded
 yet to my request for approval of this mechanical edit. They have not
 indicated a time span they need to decide, or even acknowledged
 receipt, so at this moment, I cannot give any further information on
 whether or when the mechanical edit will happen.

 It sounds strange to me that the DWG would approve an edit beforehand.
 Usually it is the community to approve such actions (if they are possible at
 all). Where did you get the idea from that DWG should or would approve a
 mechanical edit?

Matthijs says it quite clearly in his proposal page: Although not a
formal requirement either, I have asked the Data Working Group for
permission before carrying out this edit.

(You may be right that it's odd to get the DWG explicitly involved in
such pre-approval, and they might not want to set that precedent...
but I guess the DWG will have more to say about that than me...)

Dan

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


Re: [Tagging] Propose the tag shop=military_surplus

2013-12-06 Thread Dan S
2013/12/6 Axelos gnu...@laposte.net:
 Hello

 Le 05/12/2013 12:16, SomeoneElse a écrit :

 Axelos wrote:


 I proposed the tag shop=military_surplus for the shops selling used
 military equipment.
 http://wiki.openstreetmap.org/wiki/Military_surplus


 If you think that it makes sense to tag a particular shop that way just go
 ahead and use it.  You can use any tags you like.  Taginfo can see 9 others
 so far:

 http://taginfo.openstreetmap.org/search?q=military+surplus#values

 You can also have a look in taginfo for other possible shop values that
 might apply - it could be that one of those is used by people instead of
 military_surplus.

 Cheers,

 Andy

 The wiki is not intended to suggest tags to make homogeneous the database ?

Yes, but proposing/voting is not really important for simple cases
like this - you want to tag shop=military_surplus, you should go ahead
- there's no need to make big formalities of it, people use all sorts
of shop=* tags. If you want to make a wiki page for that tag, please
do make a wiki page, but don't feel you need to add rfc/voting/etc to
it. I'd suggest you remove the {{Proposal_Page}} template, and carry
on mapping :)

Dan

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


Re: [Tagging] preproposal : internet webcam

2013-11-28 Thread Dan S
2013/11/28 Egil Hjelmeland pri...@egil-hjelmeland.no:
 I have to my surprise not been able to find any established practice for
 tagging webcams on internet. I am thinking of cameras that display a place,
 so you can click in to see the weather, snow conditions and such. As a
 service to the public, not to Big Brother. So I feel man_made=surveillance
 is wrong. Also I suspect most surveillance cameras are not public on
 internet.

I would like to (politely :) disagree with your split.
man_made=surveillance seems to be perfect IMHO. The word
surveillance may feel big-brotherish, but it is literally what a
webcam does. It seems to me you could come up with some nice tags to
add to the surveillance scheme, such as webcam=public

Best
Dan

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


Re: [Tagging] Proposal - voting finished - man_made=lamp

2013-11-26 Thread Dan S
2013/11/26 Pieren pier...@gmail.com:
 On Tue, Nov 26, 2013 at 12:44 PM, Dan S danstowell+...@gmail.com wrote:

 Where can I read the rules? I searched the wiki for voting tag
 proposals etc and couldn't find them.

 On the Proposed_features main page.

Thanks.

 But don't read it as hard-coded
 rules but more as recommendations. I don't like when people think
 that the wiki is the bible. But I also don't like people saying that
 the vote process should be completely ignored. Take it as a good
 opportunity to express verbally a maximum of feedbacks, opinions and
 arguments about tags in OSM. It's better than nothing.

I agree strongly. In this case, with an almost perfectly inconclusive
result, I would say it is unfair to stamp the proposal as rejected
since there was not a majority no-vote; but equally wrong to stamp it
as sort-of-accepted (these are the two main positions in this thread
so far!). The message from the voters is clear: maybe, but not in this
exact form. Maybe the authors of the proposal will refine it to a
stronger proposal, or maybe they won't. But it seems to me that some
informal evolution is the next thing to consider, rather than repeated
rounds of hyper-formalised proposing and voting.

Dan

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


Re: [Tagging] tag for co-working spaces

2013-11-25 Thread Dan S
2013/11/25 sabas88 saba...@gmail.com:
 2013/11/25 Severin MENARD severin.men...@gmail.com

 Hi,

 Seems this does not exist yet. Here is the taginfo situation
 http://taginfo.openstreetmap.org/search?q=working_space#values

 What about a office=co_working_space or office=co-working_space?

 Hi,
 I'd prefer something like office=coworking, which is used

 http://taginfo.openstreetmap.org/search?q=coworking#values

office=coworking sounds nice

 (the amenity tag shoudn't be used imho)

+1

Dan


 Sincerely,

 Severin


 Regards,
 Stefano

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



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


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


Re: [Tagging] Wind turbines: big and small

2013-10-27 Thread Dan S
Thanks all for the thoughts about distinguishing wind turbines that
are/aren't landmarks. Personally I quite liked the landmark=yes
suggestion but, looking at the current tagging, I saw that it simply
has never been used with wind turbines. (Also, the wiki page for
landmark is very ambivalent.) landmark=windmotor is mentioned in the
wiki, and has been used 36 times, but again, the wiki is ambivalent,
suggesting it's not normally to be used.

On the other hand, man_made=tower has been used hundreds of times in
combination with wind turbine tags. Now, marking something as being a
tower doesn't make a 100% definite indication of significance. But
since it's already in use, verifiable, and in most cases it goes along
with the distinction I have in mind, I think I intend to go along with
that - I'll add man_made=tower wind turbines that I map, when indeed
they are towers.

Best
Dan


2013/10/7 Dan S danstowell+...@gmail.com:
 Hi all,

 One of the things I noticed at SOTM was that the Aston campus has two
 little wind turbines, perched on top of some of the buildings. They're
 quite small, yet the standard OSM style shows them even at zoom level
 15, as if they're significant landmarks:

 http://www.openstreetmap.org/?mlat=52.4849mlon=-1.8899#map=15/52.4849/-1.8899

 The relevant tags on these items are
generator:source = wind
power = generator
power_source = wind

 I've no problem with them being rendered, but I'd suggest it'd be
 better to show them only at finer zoom levels. However, as far as I
 can tell our renderers don't have much choice, because there's no
 tagging that distinguishes a tiny building-mounted turbine from a
 massive free-standing turbine.
 http://wiki.openstreetmap.org/wiki/Tag:generator:source%3Dwind
 In open areas with wind-farms, the turbines are significant landmarks,
 so I can see it makes sense to render them then.

 I'm suggesting this is not a problem we can leave for the renderer,
 since the renderer doesn't know the turbine's significance - it
 doesn't know if the turbine is 5 feet high or 50 feet high. (This
 implies that tagging the height could be a solution... might be a bit
 tricky to get correct height data though...)

 Best
 Dan

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


Re: [Tagging] tourism=guest_house or tourism=bed_and_breakfast ?

2013-10-17 Thread Dan S
2013/10/17 Martin Vonwald imagic@gmail.com:
 Hi!

 2013/10/17 Pieren pier...@gmail.com

 So, I'm looking if we could reuse the two existing tags
 or if I should create a sub-tag like tourism=guest_house +
 guest_house=bed_and_breakfast or
 guest_house=whatever_in_an_independent_building


 +1 for the sub-tags.

Sounds fine to me. My understanding is that tourism=bed_and_breakfast
has been used here and there, but then a mild consensus emerged just
to use tourism=guest_house, and the wiki reflects that (i.e. it
doesn't suggest tourism=bed_and_breakfast but there are some small
mentions of it remaining). Sub-tags might turn out to be useful, don't
seem harmful...

Dan

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


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

2013-10-16 Thread Dan S
2013/10/16 Martin Koppenhoefer dieterdre...@gmail.com:


 Am 16/ott/2013 um 09:23 schrieb Volker Schmidt vosc...@gmail.com:

 This feature of JOSM indicates to me that there is most likely widespread 
 use of bicycle=no on crossings with the meaning of bicycle=dismount.

 there is really no difference in meaning between bicycle=no (cycling is 
 legally forbidden) and bicycle=dismount (you may not cycle here legally)

Martin, your statement here is the same as the one which fly used to
start this thread, and a few of us in the UK have pointed out that
there is indeed a difference between two situations, both of which
occur often:
* cycling AND pushing a cycle are forbidden (which, UK-based, I
consider bicycle=no)
* cycling BUT NOT pushing a cycle is forbidden (which, UK-based, I
consider bicycle=dismount)

The problem is that different groups of people have interpreted
bicycle=no differently. That's the problem that this thread should
address, if it achieves anything. But it is not helpful when you
assert there is really no difference in meaning.

Best
Dan

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


[Tagging] Wind turbines: big and small

2013-10-07 Thread Dan S
Hi all,

One of the things I noticed at SOTM was that the Aston campus has two
little wind turbines, perched on top of some of the buildings. They're
quite small, yet the standard OSM style shows them even at zoom level
15, as if they're significant landmarks:

http://www.openstreetmap.org/?mlat=52.4849mlon=-1.8899#map=15/52.4849/-1.8899

The relevant tags on these items are
   generator:source = wind
   power = generator
   power_source = wind

I've no problem with them being rendered, but I'd suggest it'd be
better to show them only at finer zoom levels. However, as far as I
can tell our renderers don't have much choice, because there's no
tagging that distinguishes a tiny building-mounted turbine from a
massive free-standing turbine.
http://wiki.openstreetmap.org/wiki/Tag:generator:source%3Dwind
In open areas with wind-farms, the turbines are significant landmarks,
so I can see it makes sense to render them then.

I'm suggesting this is not a problem we can leave for the renderer,
since the renderer doesn't know the turbine's significance - it
doesn't know if the turbine is 5 feet high or 50 feet high. (This
implies that tagging the height could be a solution... might be a bit
tricky to get correct height data though...)

Best
Dan

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


Re: [Tagging] Pre-proposal: gambling

2013-10-05 Thread Dan S
2013/10/5 Matthijs Melissen i...@matthijsmelissen.nl:
 There are currently various tags for gambling-related shops and amenities
 in use, including amenity=casino, shop=bookmaker, shop=betting,
 shop=lottery, and shop=gambling. See here for an overview of usage
 statistics:
 http://wiki.openstreetmap.org/w/index.php?title=Proposed_features/gambling

 I notice that many users suggest distinguishing between casinos with
 croupiers, and amusement arcades with just slot machines.

Do you? I don't see that, but maybe I've missed it in the thread.

 Currently, both of
 them are grouped in one tag, amenity=casino.

 How would the community suggest establishing this split in tags? From a
 previous discussion, it seems that some users do suggest not to (re)define
 existing tags that are already in widespread use. Moreover, it seems that
 some users think that mappers should follow existing use, not definitions as
 voted or definitions from the wiki. However, I don't see how the split of
 meaning of the tag can be established otherwise. Any suggestions?

It's not difficult to handle. You could propose a chained tag such as
casino=croupier/casino=self_service, or something like
casino:staffed=yes or casino:croupier=yes. That second option
looks ugly to me, but the first option looks kinda useable. I don't
have any strong opinions about what should be done.

Note that this has quite a strong analogy with the recent discussion
about supervised vs unsupervised play areas for children...

Dan

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


Re: [Tagging] Howto tag a play room

2013-10-01 Thread Dan S
2013/10/1 Martin Koppenhoefer dieterdre...@gmail.com:

 2013/10/1 Дмитрий Киселев dmitry.v.kise...@gmail.com

 How to tag them?
 As playground=playroom with some additional tags, or it's better to use
 individual leisure=playroom tag?




 are you going to add an attribute to the supermarket or map the playroom
 with its own geometry?
 According to the wiki the playground tag is used to tag individual
 playground equipment: http://wiki.openstreetmap.org/wiki/Key:playground like
 a sandpit etc.

 If you don't consider the playroom a single playground equipment you could
 use leisure=playroom like you suggested, or maybe leisure=playground
 together with indoor=yes?

Sounds OK to me - it seems to me that the main differences from a
typical playground can be treated as attributes (indoor=yes,
supervised=yes).

 Btw.: the current definition for leisure=playground says: Marks a
 children's playground. These are commonly small outdoor areas with
 children's play equipment such as swings, climbing frames and roundabouts.
 2 questions:
 1. does commonly small outdoor area mean that uncommon ones can be indoor
 and marked with the same tag?
 2. why do they have to be small? How big is small?

My reading of commonly in that sentence implies that there is no
need for them to be small, nor outdoor. It indicates that the sentence
is just an illustration, not a constraint. I think the sentence works
for a first-language speaker, but if you think it needs to be clearer
(for non-native speakers), please do edit.

 My suggestion is to remove the words small and commonly and to decide
 whether they have to be outdoor and what would be the suggestion for indoor
 (e.g. playroom).

Sounds good to me.

Best
Dan

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


Re: [Tagging] Post vote clean up

2013-09-26 Thread Dan S
I think you just need to delete this line:
[[Category:Post-vote clean-up]]

?

Dan



2013/9/26 bredy bredy...@yahoo.it:
 The proposal is this  amenity=toilets
 http://wiki.openstreetmap.org/wiki/Proposed_features/Tag:amenity%3Dtoilets

 It'is in Approved and in Post vote list



 --
 View this message in context: 
 http://gis.19327.n5.nabble.com/Post-vote-clean-up-tp5779068p5779097.html
 Sent from the Tagging mailing list archive at Nabble.com.

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

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


Re: [Tagging] Feature Proposal - RFC - shop=musical_instrument

2013-09-24 Thread Dan S
And British English too - but, that ship has sailed.

Dan

2013/9/23 Bryce Nesbitt bry...@obviously.com:
 But in American English one does talk about a shoe shop, even though all
 that's on offer there are pairs of shoes.

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


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


  1   2   >