> On May 16, 2015, at 10:29 PM, pmailkeey . <pmailk...@googlemail.com> wrote:
>
> Thanks for the post, John.
>
Thanks for reading ^^
> I think the problem is the tagging method. Why does there have to be two
> parts to it ?
beyond necessary database syntax (key=value), This is a flat vs hierarchical
question. Do we have Education=school / school=elementary or just
school=elemntary by itself?
There is data to be gleaned from the hierarchical approach - it is an education
facility. It is not a private tutoring shop. it is a member of other similar
facilities in education (Junior high, High, University, etc).
In some cases the more complicated method makes it easier to find what is in a
category, such as a top level tag holds all the building types (building=shop)
and then shop holds all the different shop types (shop=groomer). and we can
then create an additional tag (groomer=poodle_groomer) if we need to add more
information. And the debate rages on if it should be that or
shop:groomer=poodle or similar - but that still is a hierarchy of information.
building=poodle_groomer contains less information and is less easily understood
by mappers and renderers.
>
> Landuse=schoolgrounds is the same as schoolgrounds. Natural=forest is the
> same as simply forest.
key=value.
so.. schoolgrounds=yes?
>
> How about:
>
> Forest=natural ?
isn’t that natural=wood?
>
> or forest=man_made ? [=plantation or somesuch term for a human-planted
> forest].
A forest is a man-altered area, so i believe “forest” already implies man-used.
But it is not man_made (as a building is), as the forest is not a non-building
structure.
>
> landuse=school is, to the map, the same as
> area=school which is the same as
Area is the name for a type of unit in the database (node, way, area) so that
sounds confusing. so how about using land=school for your example.
> "school" or perhaps
> school=primary
> school=secondary
> school=music
When I have a facility which encompasses multiple buildings with different
purposes (a music school , a computer school, a sports facility, etc) and that
entire facility is considered a “school” with a singular name (FooBar
university), there has to be some kind of *generic purpose-based tag* for the
area. that is how I see landuse=* . You can reimagine it to have other names,
or other tagging styles, but eventually you will lead yourself to
purpose=education because if you go much narrower, the world is so varied that
the 6 categories you need don’t quite line up with the 6 I need, and the 12
someone else needs - so to have a single catch all is much more flexible. Maybe
we can agree on some age splits (Pre K-12 , higher) but if you start going
deeper than that - what about combined primary-secondary? what about combined
secondary-high? What about a facility that does K-12 all on the same campus?
making 35 different tags is not helpful to get taggers tagging and renderers
rendering.
my fictional tag example
landuse=school [currently amenity=school]
school=k-12
k-12=secondary;high
religion=buddhist
denomination=honen
Name=FooBar Buddhist Junior & Senior High School
secondary=3
high_school=3
vs
land=honen_buddhist_secondary_high_school
This basic hierarchical approach makes it easy to support new users (unless
everything is abstracted away, which it is totally not) and Major things to be
supported by renderers (which are really really conservative) so we get the
best of all worlds for a large amount of things that can fit easily into some
big catch-all category, and still have it refined by the subtags for further
use .
All the renderers need to see is “ landuse=school “ and I get my render. The
rest is for completeness’ sake.
imagine the values needed to support land=* in your scheme. land=* would have
hundreds of unrelated types of areas all jammed together. there is no split to
them for parsing or rendering.
and any new value would have to be supported by updating all the renderers.
I can create a new value of k-12= and nothing needs to be changed, until
support for rendering the k-12 tag is supported later.
>
> The big point is what does 'landuse' (or 'natural') tell us that's new
> information
landuse can be read as “purpose”
Natural can be read as “existing in the world with little to no alteration by
man."
> ? bridge=natural would be a case where natural is giving information as it is
> not expected bridges to be natural.
a natural bridge (like a rock crossing a chasm) sounds cool.
>
> Can you find a sports pitch that's not landuse ? there's no need to have
> landuse=sports_pitch. And to prove my point, OSM doesn't ! we have instead
> leisure=sports_pitch - but it's still landuse but not tagged as such. So now,
> it seems OSM tags landuse on its own whims, is inconsistent; is confusing
A commercial sports facility would have a landuse encompassing all the pitches,
parking lots, and other buildings (leisure=sports_center) that make up FooBar
Sports Center.
landuse=commercial (i think)
name:foobar Sports Center
sport=multi
I could see there being a landuse=recreation or leisure, but we have chosen to
define a lot of land uses by economic means (commercial, industrial,
residential, agriculture, etc).
This lack of completeness in landuse (there is no landuse=civic yet, I’m
pushing for it) would help solve some issues, IMO.
Very specific landuses (landuse=poodle_training_ground) sounds really bad to
me. there are some which should have been sub-keys (like farmland+crop) but no
one was looking that far ahead, such as
landuse=farmland now instead of landuse=agriculture and agriculture=* would be
better, rather than trying to get rendering support for more esoteric landuse
values (like greenhouse_horticulture).
>
> landuse=golf_course
> leisure+golf_course
(bad syntax)
> man_made=golf_course
landuse=commerical (private business, as opposed to a city operated course, or
a company that um.. sells golf courses ^^)
something something =sports facility
sport=golf
golf courses are not a non-building structure (like a dam or a tower) so it is
not in man_made
golf=foobar (as there is so, so, much defined about golf courses).
how and where we slice the “sports facility” pie - there are thousands of golf
courses all over each country, so they might warrant their own tag - is up to
how tag definers care to define it.
The die-hard golf course taggers can hide all their esoteric crap inside golf=
so a regular joe can tag the facility without understanding traps and roughs
and fairways and whatever.
This scheme makes support for rendering “sports facilities” or “golf courses”
much easier - rather than all the esoteric course types that could fill up a
tag space.
>
> Surely all three of these are 'obvious' when referring to a golf course ? If
> they're not the obvious - then tag differently: golf_course=electronic.
this should merely be a value of golf=* (golf=virtual_golf?)
building=yes
sport=golf
golf=virtual_golf (used for practicing swings in an indoor and very space
limited area while being immersed in a virtual play field).
Maybe, but once you start cutting up the pie into different sections, you can't
slice the same pie two different ways, so we need to make decisions. And these
are all sub-optimized organically made community decisions - and some people
see a great value in that.
>
> OSM tagging is not logical. Does it need to be ? no, but it would help if it
> was.
I think we are both seeing incompleteness in the tagging schema because it was
made organically, and we both want to complete the sections that our mind most
easily latches onto to make OSM better - but there are good and bad points to
each way, and because of the multitude of people, the only way to change OSM is
one tag at a time - which is frustrating, but the “grand retagging” schemes are
all doomed to failure, even if we are not opposed to them.
Please remember syntax is important as well - and I think language influences
this a lot - how we define the world is related to our language. and OSM is
filed with different taggers from different languages.
"I want to go to that restaurant." would be “I = that restaurant to gowant. “
(私 は あの レストラン に 行きたい。) in Japanese. Note “want" is stuck on the verb.
How Japanese people would make OSM syntax and tag categories would (probably)
be very different - so we will always have this battle.
Javbw
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
