On Mar 30, 2015 11:05 PM, "Bryce Nesbitt" wrote:
>
> On Mon, Mar 30, 2015 at 2:51 PM, fly wrote:
>>
>> Am 30.03.2015 um 23:35 schrieb John F. Eldredge:
>> > It's about time that renderers started supporting semicolon-delimited
lists. Splitting apart a delimited string is a trivial programming tas
On Mar 29, 2015 1:28 AM, "David Bannon" wrote:
>
> On Sat, 2015-03-28 at 21:57 -0700, Bryce Nesbitt wrote:
> > wrote:
> > Just a note about using semicolon-delimited lists. Most
> > renderers do not handle such lists very well so a tag like the
> > following:
> >
On Tue, Mar 31, 2015 at 1:40 AM, Martin Koppenhoefer
wrote:
> +1, often mappers use semikolon separated lists on the same object for what
> should actually be more than one object (in cases where a main tag has
> multiple values). This is not working. But it is normally no problem to use
> multiva
2015-03-31 8:08 GMT+02:00 Dave Swarthout :
> amenity=toilets;drinking_water
> fee=no
> opening_hours=24/7
> toilets:position=seated;urinal
>
> Yes, good information. There is much ambiguity in that example if the
> tagging is not done carefully and properly.
+1, often mappers use semikolon sepa
amenity=toilets;drinking_water
fee=no
opening_hours=24/7
toilets:position=seated;urinal
Yes, good information. There is much ambiguity in that example if the
tagging is not done carefully and properly.
On Tue, Mar 31, 2015 at 11:03 AM, Bryce Nesbitt
wrote:
> On Mon, Mar 30, 2015 at 2:51 PM, fly
On Mon, Mar 30, 2015 at 2:51 PM, fly wrote:
> Am 30.03.2015 um 23:35 schrieb John F. Eldredge:
> > It's about time that renderers started supporting semicolon-delimited
> lists. Splitting apart a delimited string is a trivial programming task. I
> know, having worked as a programmer for the last
I asked what the OSMAnd developers prefer but have not yet had an
answer. On their forum by the way, works well !
David
On Tue, 2015-03-31 at 07:11 +0700, Dave Swarthout wrote:
> It's about time that renderers started supporting semicolon-delimited
> lists. Splitting apart a delimited string is
It's about time that renderers started supporting semicolon-delimited
lists. Splitting apart a delimited string is a trivial programming task. I
know, having worked as a programmer for the last 29 years.
+1
Speaking as an ex-programmer, I completely agree
PHP, and other languages, actually have
Am 29.03.2015 um 11:27 schrieb Bryce Nesbitt:
> On Sun, Mar 29, 2015 at 1:37 AM, Warin <61sundow...@gmail.com> wrote:
>
>> What if you do know details .. but not the exact location? Still place a
>> node somewheres?
>>
>
> How about at that point you go visit the site, and map based on that visit
Am 30.03.2015 um 23:35 schrieb John F. Eldredge:
> It's about time that renderers started supporting semicolon-delimited lists.
> Splitting apart a delimited string is a trivial programming task. I know,
> having worked as a programmer for the last 29 years.
+1
cu fly
It's about time that renderers started supporting semicolon-delimited lists.
Splitting apart a delimited string is a trivial programming task. I know,
having worked as a programmer for the last 29 years.
On March 28, 2015 11:09:10 PM CDT, Dave Swarthout
wrote:
> Just a note about using semic
On Sun, Mar 29, 2015 at 1:37 AM, Warin <61sundow...@gmail.com> wrote:
> What if you do know details .. but not the exact location? Still place a
> node somewheres?
>
How about at that point you go visit the site, and map based on that visit.
OSM has a ten year history: have a look at existing co
On 29/03/2015 6:14 PM, Dave Swarthout wrote:
On Sun, Mar 29, 2015 at 2:12 PM, Dave Swarthout
mailto:daveswarth...@gmail.com>> wrote:
But does having a JOSM preset that sets a tag bar=yes mean that
the bar actually gets rendered, or is it just findable though a
query you can make t
On Sun, Mar 29, 2015 at 2:12 PM, Dave Swarthout
wrote:
> But does having a JOSM preset that sets a tag bar=yes mean that the bar
> actually gets rendered, or is it just findable though a query you can make
> to OSMAnd or whatever? It all depends on which map or which renderer you're
> talking abo
But does having a JOSM preset that sets a tag bar=yes mean that the bar
actually gets rendered, or is it just findable though a query you can make
to OSMAnd or whatever? It all depends on which map or which renderer you're
talking about does it not?
On Sun, Mar 29, 2015 at 1:39 PM, Bryce Nesbitt
On Sat, Mar 28, 2015 at 11:26 PM, David Bannon
wrote:
> So this is, IMHO, the crucial question. I've been too scared to ask it
> in fear of being accused to Tagging for the Render. Is the
> [SomeAmenityValue=yes] preferred by the rendered over a delimited list ?
> Can we get that authoritatively
On Sat, 2015-03-28 at 21:57 -0700, Bryce Nesbitt wrote:
> wrote:
> Just a note about using semicolon-delimited lists. Most
> renderers do not handle such lists very well so a tag like the
> following:
> amenity=bar;restaurant;picnic_table;sanitary_dump_station
> M
On Sat, Mar 28, 2015 at 9:09 PM, Dave Swarthout
wrote:
> Just a note about using semicolon-delimited lists. Most renderers do not
> handle such lists very well so a tag like the following:
> amenity=bar;restaurant;picnic_table;sanitary_dump_station
>
Most rendering will show nothing for such tag
Just a note about using semicolon-delimited lists. Most renderers do not
handle such lists very well so a tag like the following:
amenity=bar;restaurant;picnic_table;sanitary_dump_station
might not show you all of the amenities. There have been many discussions
about this issue on this list and e
On Sat, 2015-03-28 at 12:26 +0100, Marc Gemis wrote:
> If I am on a large campsite I want to use "the map" to find my way to
> all amenities. If you have put everything on 1 node it's a pretty
> useless map, not ?
Agree in principle Marc but don't think its always practical. I have
been to many c
Have you noticed how few people participate in votes and tagging
discussions?
The wiki vote process relates to the wiki.
OSM has an open tagging system, and many users never read or interact with
the wiki.
Success of a wiki vote may or may not lead to a change in mapping behaviour.
On Sat, Mar 2
So what is the voting for then:
http://wiki.openstreetmap.org/wiki/Proposal_process?
On Sat, Mar 28, 2015 at 9:57 PM Bryce Nesbitt wrote:
> On Sat, Mar 28, 2015 at 1:16 PM, Jan van Bekkum
> wrote:
>
>>
>>> It means that you create new tags for objects for which approved tags
>>> already exist,
On Sat, Mar 28, 2015 at 1:16 PM, Jan van Bekkum
wrote:
>
>> It means that you create new tags for objects for which approved tags
>> already exist, such as amenity=shower and leisure=swimming pool, this is
>> not a good practice.
>>
>
1) There's no such thing as *approved*.
2) The tagging style i
>
>
>
> What if I know the camp site has a showers, a swimming pool and a dump
> station, but I don't know where on the site they are?
> Thus:
>
> *tourism=camp_site*
> *showers=yes*
> *swimming_pool=yes*
> *dump_station=yes*
>
>
> It means that you create new tags for objects for which approved ta
On Sat, Mar 28, 2015 at 2:27 AM, Jan van Bekkum
wrote:
> Bryce
> This is not the right example. All tags in your example are attributes
> that belong to the camp_site, no need for extra nodes; you are fully
> correct there.
>
> What I am talking about is multiple namespace tags in a single node:
> Am 28.03.2015 um 07:17 schrieb Jan van Bekkum :
>
> g that clearly isn't the real shape ( a small square or a circle) and put all
> nodes within it.
a square clearly reduces impact on the db, as 4 nodes are sufficient, from that
point of view, a triangle is even better ;-)
Cheers
Marti
Conclusion for my own mapping efforts from the discussion so far: start
with stacked amenities until you know something about the campsite
topology, then make nodes/polygons per amenity.
On Sat, Mar 28, 2015 at 12:58 PM Martin Koppenhoefer
wrote:
>
>
>
>
> > Am 28.03.2015 um 12:26 schrieb Marc G
> Am 27.03.2015 um 17:21 schrieb Bryce Nesbitt :
>
> Site relations are clearly the best solution when micro-mapping.
site relations are only adding value when you want to connect objects that are
not already spatially connected, or when you want to use fancy roles (eg this
parking, not on
> Am 28.03.2015 um 12:26 schrieb Marc Gemis :
>
> If I am on a large campsite I want to use "the map" to find my way to all
> amenities. If you have put everything on 1 node it's a pretty useless map,
> not ?
+1, IMHO the ideal mapping should be an area for the camp site, and features
sho
On Sat, Mar 28, 2015 at 1:32 AM, Bryce Nesbitt wrote:
> The advantage of the single node approach is you can make a list of camp
> sites and their amenities really easily,
> and you can click once on a campsite tag, and understand what's there.
>
I thought we collected data to create maps, not t
Bryce,
This is not the right example. All tags in your example are attributes that
belong to the camp_site, no need for extra nodes; you are fully correct
there.
What I am talking about is multiple namespace tags in a single node:
tourism=camp_site
amenity=restaurant;shower;bar;swimming_pool
shop
On Fri, Mar 27, 2015 at 11:17 PM, Jan van Bekkum
wrote:
> What do I see on the map when I use the stacked amenity model?
>
Tagging for today's rendering is hazardous.
The stacked amenity model is quite common. Nothing seems broken about it
at all.
For example:
http://www.openstreetmap.org/node
What do I see on the map when I use the stacked amenity model? A campsite
symbol with a restaurant below it or a restaurant symbol with a campsite
below it? A search in OsmAnd will give me the campsite in all cases, but it
cannot always show all tags below it, so I don't know all amenities by
looki
On Fri, Mar 27, 2015 at 2:24 PM, Warin <61sundow...@gmail.com> wrote:
> OR .. you could place each node of the separate features close together
> with a fixme tag on them ...
> This way you don't need two systems for tagging the same thing. And it
> makes it easier for a mapper to move them to th
On Fri, 2015-03-27 at 14:07 +, Jan van Bekkum wrote:
> It is a bit of a philosophical question: do you prefer a placeholder
> or a polygon of which you don't know how correct it is, for example a
> forest behind the campsite that may or may not be part of the
> campground.
In natural surroundi
On 28/03/2015 3:21 AM, Bryce Nesbitt wrote:
Site relations are clearly the best solution when micro-mapping.
But this is not a one size fits all choice. There are many mappers,
tools, and places that are not ready for that level of complexity.
We're lucky to get many campsites mapped at all.
Site relations are clearly the best solution when micro-mapping.
But this is not a one size fits all choice. There are many mappers, tools,
and places that are not ready for that level of complexity.
We're lucky to get many campsites mapped at all. In simple cases a few
attributes on a node does
It is a bit of a philosophical question: do you prefer a placeholder or a
polygon of which you don't know how correct it is, for example a forest
behind the campsite that may or may not be part of the campground.
On Fri, Mar 27, 2015 at 1:57 PM Marc Gemis wrote:
> In many cases you will be able
In many cases you will be able to determine the area from the aerial images
(thinking of Western European campsites).
I assume that in the campsites you visited, the actual area was rather
fuzzy and that the exact area will never been known, not ? OSM has no
solution for fuzzy areas anyhow.
Is it
So if you don't know the real shape of the polygon it would be best to
create a placeholder polygon (like a circle - it will be clear that it is a
placeholder) and put all amenities inside it until the real shape is known.
On Fri, Mar 27, 2015 at 10:33 AM Marc Gemis wrote:
> Overpass understands
Overpass understands this. When I look for all toilets in the "Zoo
Antwerpen" with [1], I only find toilets in that Zoo
regards
m
[1] http://overpass-turbo.eu/s/8qL
On Fri, Mar 27, 2015 at 10:24 AM, Marc Gemis wrote:
>
>> OK, I did not know that ! Is this "is-in-polygon" test something that
>
>
> OK, I did not know that ! Is this "is-in-polygon" test something that
> is already being done ? Examples ?
>
Nominatim that adds the address of the building to the POI is an example of
a similar test / algorithm.
Sorry, don't know any other examples. But it just makes sense that you do
not
On Fri, 2015-03-27 at 09:58 +0100, Marc Gemis wrote:
> "It is not necessary or appropriate to use a relation when all the
> elements contained within the boundary of the site belong to the site,
> and no elements beyond that boundary do belong. In this simple case
> simply tag the perimeter with a
Please remember
"It is not necessary or appropriate to use a relation when all the elements
contained within the boundary of the site belong to the site, and no
elements beyond that boundary do belong. In this simple case simply tag the
perimeter with all the appropriate tags. Users of the informa
On Fri, 2015-03-27 at 07:31 +, Jan van Bekkum wrote:
> Separate nodes for campground and amenities connected in a site
> relation
Only practical solution IHMO.
David
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.opens
Apply 3 in case all amenities fall in 1 area.
Apply 4 in case they are in separate areas.
Use 1 only in a first iteration when no more details are known.
don't like 2 at all :-)
I think camp sites are no different that large factories, schools,
universities etc. in this respect.
regards
m
On
On 27/03/2015 6:31 PM, Jan van Bekkum wrote:
This is a spinoff of a discussion that was started in the mail trail
about the proposal for camp_site=* that is currently open for
comments. I would like to limit this discussion to facilities for the
entire campground, not individual pitches. Simila
I like the values you proposed (the camp_site=opportunistic_hospitality email)
and option #4 here - if the relation values are straight forward, then people
will make the jump to learn it.
I also suggest a fallback note on the proposal,, such "as map the area,
amenities, and information as bes
This is a spinoff of a discussion that was started in the mail trail about
the proposal for camp_site=* that is currently open for comments. I would
like to limit this discussion to facilities for the entire campground, not
individual pitches. Similar questions will apply to other situations than
c
49 matches
Mail list logo
