Re: [Tagging] Seasonal, intermittent, and ephemeral water tags

2018-05-19 Thread Vao Matua
For remote mappers seasonal can be ambiguous, the only thing that is known
is that a channel or lake didn't have water when the image was taken.
In the tropics the notion of summer doesn't make sense, it's a foreign
concept.
intermittent=yes is a fine tag

On Sat, May 19, 2018 at 3:29 PM, Warin <61sundow...@gmail.com> wrote:

> On 19/05/18 13:25, Tod Fitch wrote:
>
> On May 18, 2018, at 7:33 PM, Warin <61sundow...@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> I seek comments and thoughts on
>>>
>>> -
>>>
>>> Seasonal:
>>>
>>> The seasonal tag in well established. I don't think there is much
>>> confusion with it.
>>>
>>>
>>> ---
>>>
>>> Intermittent:
>>>
>>> The intermittent tag continues to be confused with seasonal.
>>>
>>> Possibly this is because some want to use it to indicate that a follow
>>> is both seasonal and intermittent?
>>>
>>>
>>> -
>>>
>>> Ephemeral:
>>>
>>> There is also ephemeral being used with stream=ephemeral. This cannot be
>>> used with other water features e.g. lakes.
>>>
>>> I think the tag ephemeral=yes could be used, other ideas for tagging are
>>> flow=ephemeral, water=ephemeral ...
>>>
>>>
>>> ---
>>>
>>> Combinations with seasonal?
>>>
>>> Think I have raised this before but not come to any firm conclusion
>>> myself.
>>>
>>> I think that tagging
>>>
>>> seasonal=summer
>>>
>>> intermittent= yes
>>>
>>>
>>> leads to confusion. Is the summer flow intermittent? Or is ther regular
>>> summer flow with intermittent flow at other times of year?
>>>
>>> It may be better to tag
>>>
>>> seasonal:intermittent=summer
>>>
>>>
>>> or
>>>
>>> seasonal=summer
>>>
>>> seasonal:intermittent=winter;autumn;spring
>>>
>>> In the semi-arid areas I’ve lived in there are “waterways” that, if they
>> carry water, only have water in them during the rainy season. But, they may
>> not carry water throughout the rainy season. Or even carry water at all
>> every rainy season. So I can see some merit to indicating the seasonality
>> of intermittent water flow.
>>
>> If I recall correctly, there was some discussion a while back about using
>> ephemeral as either a key or as a value to the intermittent key to cover
>> the case where even during a rainy season it would be rare to encounter
>> water and if you did the water was likely to be present for only a few
>> hours. But looking at the wiki and taginfo I don’t see it being used as a
>> value for intermittent. There are only 82 instances of it being used as a
>> key all with the value “yes". And I don’t recall the final “bike shedded”
>> result of the mail list discussion. Apparently it did not take hold. I
>> personally thing “ephemeral” should be a accepted value for the
>> intermittent tag but apparently I am alone in that opinion.
>>
>> In any case, your “seasonal:intermittent=summer” tag could also be
>> confusing. Does that mean that the only time you are likely to encounter
>> water is in summer but it is only intermittent then? Or does it mean that
>> there is likely to be water in it during fall, winter and spring but it
>> becomes intermittent in summer? Basically has the same issue as the current
>> tagging you are noting as being confusing.
>>
>> In reading the current wiki, I think the tagging should be a logical and
>> operation. If there is a seasonal tag, it indicates the season water may be
>> present. Then if there is a intermittent tag it indicates that even during
>> the season water is present it is intermittent.
>>
>> Ok.
>
> I think I have some 3 reasonable things to move forward with.
>
> Intermittent clarification:
>
> Clarify the meaning of intermittent on the OSM wiki! At the moment it says
> "used to indicate that a body of water does not permanently contain water."
> That is too easily confused with seasonal! I think it should say "used to
> indicate that a body of water only has water irregularly." Where should
> this be 'discussed'?
>
> Intermittent - add values:
> Add seasonal values to intermittent e.g. intermittent=summer to indicate
> that water might be present irregularly, but only during summer. RFC etc?
>
> Add ephemeral:
> Add the ephemeral tag with the same extended values as intermittent above.
> RFC etc ?
>
>
> ___
> 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] Is it possible to have highway=unclassified with ref tag?

2018-05-07 Thread Vao Matua
There are many places where people live in Africa that could be tagged as
Rural_Residential if that tag existed.

On Mon, May 7, 2018 at 9:57 AM, Dave Swarthout 
wrote:

> yopaseopor wrote: I suggest to reclassify the other roads in their grades
> to make unclassified roads unclassified as the name says it.
>
> +1
>
> I agree with your view but this topic is full of issues. In Thailand, for
> example, we use "unclassified" for any highway that a) has no ref, and b),
> is neither a service road, track, or residential way. It is essentially a
> catchall for roads that do not fall into any other category. Again, using
> Thailand as an example, there are many small, paved roads that have few or
> no homes on them, sort of like a service road. I think some new category
> might be warranted. However, proposing such a change and then obtaining
> consensus is bound to be a difficult process.
>
> On Mon, May 7, 2018 at 12:47 PM, yo paseopor  wrote:
>
>> The topic is the classification of OSM is not the same as countries have,
>> and this make troubles. An UNCLASSIFIED road as its name says it is
>> unclassified...but when you need some road classification with a step more
>> than tertiary then you use unclassified, and if the road has ref...you put
>> in then. Why don't you reorder the tertiary roads? They also catch your
>> less thant tertiary roads in your country. Also it is the same problem with
>> trunk or primary: whatis the difference between trunk of one lane per
>> direction and a primary road? Also you have the issue if you consider the
>> administrative classification as we do some countries: a trunk may be a
>> trunk because being managed by one specific administration? WTF? Is it good
>> for the map? All the roads by a local administration should be
>> unclassified? It is a complicated problem. I suggest to reclassify the
>> other roads in their grades to make unclassified roads unclassified as the
>> name says it.
>>
>> Salut i carreteres sense classificar (Health and unclassified roads)
>> yopaseopor
>>
>> On Mon, May 7, 2018 at 5:11 PM, Richard Welty 
>> wrote:
>>
>>> On 5/7/18 10:35 AM, Rory McCann wrote:
>>> > On 06/05/18 09:41, Mateusz Konieczny wrote:
>>> >> I am pretty sure that it is entirely possible to have
>>> >> highway=unclassified
>>> >> with officially assigned and posted ref number, but I wanted to check
>>> >> whatever my edit on
>>> >> https://wiki.openstreetmap.org/wiki/Tag:highway%3Dunclassified
>>> >> was correct.
>>> >
>>> > Yes it is! AFAIR the "highway=unclassified" comes from British usage,
>>> > where "unclassified" was a road classification. Yes it sound silly. I
>>> > think the refs in the UK aren't signposted, but roads with the
>>> > unclassified classification (!) have "U" refs (e.g. "U123", instead of
>>> > "A123" etc).
>>> by convention if a ref is unposted, many folks use unsigned_ref instead
>>> of ref
>>> for example, pretty much all the rural paved roads in North Carolina
>>> have state
>>> assigned refs, but the ordinary town roads are unposted.
>>>
>>> i can imagine a jurisdiction which uses signed refs on generic
>>> "unclassified" roads,
>>> but i've never seen one. i would be reluctant to explicitly rule out the
>>> possibility.
>>>
>>> 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] Identifying language regions

2018-04-18 Thread Vao Matua
I suggest doing a Google image search for "language map Nigeria" to see how
problematic this suggestion will be.
OpenStreetMap is not a full function geospatial information tool.
Mapping thousands of languages might be tidy in North America, but will
make a mess in other parts of the world.

Vao

On Wed, Apr 18, 2018 at 3:06 PM, Frederik Ramm  wrote:

> Hi,
>
> On 04/18/2018 09:41 PM, Yuri Astrakhan wrote:
> > A relation may span multiple countries (e.g. US and most of Canada for
> > English), or split countries (e.g. EN and FR regions in Canada). In some
> > cases, the relation will reuse country border ways.
>
> We had a discussion about time zones here recently, and came to the
> conclusion that they should not be mapped as separate polygon relations,
> but instead that the time zone information should be tagged on the admin
> boundaries of a country or smaller entity; and that time zone polygons
> in their own right would only be welcome where they don't follow country
> boundaries.
>
> I have a feeling that the same will hold true for spoken languages. I
> would be very much against trying to establish fuzzy separate regions
> for language use, since the exact delineation will not be verifiable.
> The question "what is the majority/official language in region X" or
> "country Y", on the other hand, tends to have a clear answer.
>
> 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] Identifying language regions

2018-04-18 Thread Vao Matua
I would suggest that OSM is probably not the best place for this.  There
are many countries that have many or even hundreds of languages.  The lines
between the places where languages are commonly spoken can be quite fuzzy
and often do not follow any other features. A year ago I was living in a
place where people living there spoke 3 different languages in addition to
the "official" language.

On Wed, Apr 18, 2018 at 12:41 PM, Yuri Astrakhan 
wrote:

> What would be the best tags to use for mapping language regions?  I would
> like to create a map of primary languages spoken in an area. This will
> greatly help with multilingual maps, allowing data consumers to calculate
> which language name tags to use for which locale. This will also give OSM
> community a much greater control over such maps.
>
> Proposal (relations only, must have closed polygons):
> type=language
> primary=xx   (required)
> secondary=yy;zz;...  (optional)
>
> A relation may span multiple countries (e.g. US and most of Canada for
> English), or split countries (e.g. EN and FR regions in Canada). In some
> cases, the relation will reuse country border ways.
>
> 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] windthrow areas (=forest destroyed by winds, =windfall)

2018-03-16 Thread Vao Matua
A young forest is still a forest.

On Fri, Mar 16, 2018 at 2:47 PM, Mateusz Konieczny 
wrote:

> On Sat, 17 Mar 2018 07:02:07 +1100
> Frank Warner <61sundow...@gmail.com> wrote:
>
> > Would the trees naturally regenerate?
>
> > There should be seeds left behind by the old trees that would grow to
> > replace the old trees. So the area should be covered with trees ..
> > young trees but still trees.
> >
> > I much prefer landcover=* to natural and would use landcover=trees
> > for this situation.
>
> I would not expect area where no plant is higher than 50 cm to be
> described as forest. I think that using "landcover=trees" would be
> misleading in this case.
>
> ___
> 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] Culverts and Fords

2018-03-02 Thread Vao Matua
Rendering will always be an imperfect representation of the real world.
I still feel that there is an inconsistency with the way these two
circumstances are handled, but understand that this is one of the non-open
parts of Open Street Map.
I'm done trying to swim upstream on this.

On Fri, Mar 2, 2018 at 7:17 AM, Volker Schmidt <vosc...@gmail.com> wrote:

> The layers tag in OSM is only to enable the renderer to display/draw
> crossing OSM elements correctly. The element with the higher layer value is
> drown over the ones with lower layer values.
>
> In the case of the ford the waterway and the highway are on the same layer
> and share a node, which represents the ford (assuming that highway and
> waterway are line objects. If the waterway and/or the highway are drawn as
> polygons, then the ford becomes a line or a polygon.)
>
> In case of a culvert the objects are not on the same layer. The highway is
> above the waterway (which may be intermittent or a wadi). Hence a common
> node is not correct. You could argue that the culvert becomes a node on the
> lower way, that is not connected with the highway above. It would have to
> be drawn exactly on the crossing point, without being part of the highway
> above. A non-zero length culvert is most likely easier to draw, and also
> closer to reality.
> Again, when the waterway is drawn as a Polygon, the culvert becomes a
> polygon.
>
> On 2 March 2018 at 15:41, Vao Matua <vaoma...@gmail.com> wrote:
>
>> Thank you Ralph, I understand your perspective, but have to disagree a
>> bit (I'm not looking for a battle, however).
>>
>> A ford is a stack of layers that are directly adjacent vertically, with
>> the road slightly below the stream/river.  In the dry season a ford is only
>> a road and only becomes a ford when a watercourse flows over the top of the
>> road.
>>
>> A culvert is a part of of road construction, a culvert would not exist
>> without the road, but the culvert is utilized by the stream.  Personally I
>> have physically installed culverts in road profiles where there is no
>> watercourse.  If I try to add a culvert in JOSM without an additional tag I
>> get a validation warning.
>>
>> Wouldn't a road/stream crossing without a culvert or bridge be called a
>> dam?
>>
>> Isn't a culvert similar in rendering to an embankment?  An embankment is
>> a tag applied to a road or railroad, but it is a level beneath the road or
>> railroad.  A culvert happens to be perpendicular or so to the road rather
>> than adjacent to it.
>>
>> Part of this discussion also is a matter of scale.  At some rendering of
>> a map even a place like Paris would be displayed as a node.  In the same
>> way a culvert displayed as a node would be appropriate at certain zoom
>> levels.
>>
>> I think an easy solution is to make the rendering rule for culverts be a
>> layer below the road and allowed to be a node.
>>
>> I think this is an interesting discussion and is helping me understand
>> different points of view, thanks.
>>
>> Emmor
>>
>> On Fri, Mar 2, 2018 at 12:39 AM, Ralph Aytoun <ralph.ayt...@ntlworld.com>
>> wrote:
>>
>>> The real easy way to understand *culverts* and *fords* for
>>> OpenStreetMap is about the layers they are on and this dictates the nodes
>>> they use.
>>>
>>>
>>>
>>> For a  *ford* the stream/river is at the same level as the road
>>> (effectively *layer=0*) and therefore they are able to share a node.
>>>
>>>
>>>
>>> Because a culvert (*layer=-1*)  is not on the same level as the road
>>> but passes underneath so it cannot share a node with the road and therefore
>>> the culvert is attributed to the river/stream with a node either side of
>>> the road.
>>>
>>>
>>>
>>> With a *bridge* the road (*layer 1*)  is not on the same level with the
>>> stream/river so again cannot share a node and therefore the bridge is
>>> attributed to the road with a node at each end of the bridge.
>>>
>>>
>>>
>>> Hope this will be of help in understanding the problem.
>>>
>>>
>>>
>>>
>>>
>>> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
>>> Windows 10
>>>
>>>
>>>
>>
>>
>> ___
>> 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] Culverts and Fords

2018-03-02 Thread Vao Matua
Thank you Ralph, I understand your perspective, but have to disagree a bit
(I'm not looking for a battle, however).

A ford is a stack of layers that are directly adjacent vertically, with the
road slightly below the stream/river.  In the dry season a ford is only a
road and only becomes a ford when a watercourse flows over the top of the
road.

A culvert is a part of of road construction, a culvert would not exist
without the road, but the culvert is utilized by the stream.  Personally I
have physically installed culverts in road profiles where there is no
watercourse.  If I try to add a culvert in JOSM without an additional tag I
get a validation warning.

Wouldn't a road/stream crossing without a culvert or bridge be called a dam?

Isn't a culvert similar in rendering to an embankment?  An embankment is a
tag applied to a road or railroad, but it is a level beneath the road or
railroad.  A culvert happens to be perpendicular or so to the road rather
than adjacent to it.

Part of this discussion also is a matter of scale.  At some rendering of a
map even a place like Paris would be displayed as a node.  In the same way
a culvert displayed as a node would be appropriate at certain zoom levels.

I think an easy solution is to make the rendering rule for culverts be a
layer below the road and allowed to be a node.

I think this is an interesting discussion and is helping me understand
different points of view, thanks.

Emmor

On Fri, Mar 2, 2018 at 12:39 AM, Ralph Aytoun 
wrote:

> The real easy way to understand *culverts* and *fords* for OpenStreetMap
> is about the layers they are on and this dictates the nodes they use.
>
>
>
> For a  *ford* the stream/river is at the same level as the road
> (effectively *layer=0*) and therefore they are able to share a node.
>
>
>
> Because a culvert (*layer=-1*)  is not on the same level as the road but
> passes underneath so it cannot share a node with the road and therefore the
> culvert is attributed to the river/stream with a node either side of the
> road.
>
>
>
> With a *bridge* the road (*layer 1*)  is not on the same level with the
> stream/river so again cannot share a node and therefore the bridge is
> attributed to the road with a node at each end of the bridge.
>
>
>
> Hope this will be of help in understanding the problem.
>
>
>
>
>
> Sent from Mail  for
> Windows 10
>
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Culverts and Fords

2018-03-01 Thread Vao Matua
Thank you all for the explanations.
I think that my issue might have to do with UK English usage.  I  would
never call a road tunnel a "culvert", I  typically only work and map in a
rural setting and a culvert is only a passage way for water, and is only
used at a road or path crossing.

While a ford is something shared by a road and a stream one is still under
the other, but the rules for rendering assume that the road is underneath.
In the OSM ford wiki <https://wiki.openstreetmap.org/wiki/Key:ford> one
photograph shows the path on top of the ford using the stepping stones.
The Wikipedia <https://en.wikipedia.org/wiki/Culvert>reference cited on the OSM
culvert wiki <https://wiki.openstreetmap.org/wiki/Tag:tunnel=culvert> only
shows stream examples.
Therefore, why not have a rendering rule for culverts in the same way there
is a rendering for a ford?

This has been an interesting thought process and I'm probably just lazy not
wanting to split a watercourse twice and add a tag to the way as opposed to
snapping a road or watercourse node and adding a tag to the node.

Keep mapping

On Wed, Feb 28, 2018 at 5:11 PM, Dave Swarthout <daveswarth...@gmail.com>
wrote:

> >If 2 ways share a node, then they must be connected to each other. ie on
> the same layer. So one can't be above/below the other. A road and a stream
> crossing on the same layer is a ford.
> >If you tag the shared node as a tunnel, then you don't know which way
> goes through the tunnel.  Does the stream go through a tunnel, or does the
> road go through a tunnel, or both?
>
> >It is much more useful to map tunnels/bridges as a way. If you know there
> is a tunnel, but don't know how long the tunnel is, you can estimate it. ie
> based on the width of the road. You can add a note to say the exact
> >length/position is estimated
>
> Excellent explanation. Agree totally.
>
> On Thu, Mar 1, 2018 at 7:48 AM, Craig Wallace <craigw84+...@gmail.com>
> wrote:
>
>> On 2018-02-28 23:21, Vao Matua wrote:
>>
>>> François
>>>
>>> I don't have an example.  I was trying to think of an example where
>>> layer would be needed for a stream/road crossing.  A pipe would probably be
>>> a better example.
>>>
>>> Sorry to cause a distraction.
>>>
>>> My real question is "Why not allow tunnel=culvert to be a node?"
>>>
>>> Emmor
>>>
>>
>> If 2 ways share a node, then they must be connected to each other. ie on
>> the same layer. So one can't be above/below the other. A road and a stream
>> crossing on the same layer is a ford.
>> If you tag the shared node as a tunnel, then you don't know which way
>> goes through the tunnel.  Does the stream go through a tunnel, or does the
>> road go through a tunnel, or both?
>>
>> It is much more useful to map tunnels/bridges as a way. If you know there
>> is a tunnel, but don't know how long the tunnel is, you can estimate it. ie
>> based on the width of the road. You can add a note to say the exact
>> length/position is estimated.
>>
>>
>> ___
>> 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] Culverts and Fords

2018-02-28 Thread Vao Matua
 François

I don't have an example.  I was trying to think of an example where layer
would be needed for a stream/road crossing.  A pipe would probably be a
better example.

Sorry to cause a distraction.

My real question is "Why not allow tunnel=culvert to be a node?"

Emmor


2018-02-28 22:31 GMT+01:00 Vao Matua <vaoma...@gmail.com>:

> In the case where a culvert carries a watercourse over a road then it
> would make sense to create a way and layer=1
>

Can you provide examples of such a culvert please?

IMHO this can't be called a culvert since there is pretty no point to cover
the water course if it is over the road.
This maybe a canal (waterway=canal, eventually with bridge=aqueduct on it)
or the road can go through a tunnel like here :
https://photorator.com/photos/images/underwater-road-xpost-
from-rwoahdude-20901.jpg

All the best

François



On Wed, Feb 28, 2018 at 2:27 PM, François Lacombe <fl.infosrese...@gmail.com
> wrote:

> Hi,
>
> 2018-02-28 22:31 GMT+01:00 Vao Matua <vaoma...@gmail.com>:
>
>> In the case where a culvert carries a watercourse over a road then it
>> would make sense to create a way and layer=1
>>
>
> Can you provide examples of such a culvert please?
>
> IMHO this can't be called a culvert since there is pretty no point to
> cover the water course if it is over the road.
> This maybe a canal (waterway=canal, eventually with bridge=aqueduct on it)
> or the road can go through a tunnel like here :
> https://photorator.com/photos/images/underwater-road-xpost-
> from-rwoahdude-20901.jpg
>
> All the best
>
> François
>
>
> ___
> 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] Culverts and Fords

2018-02-28 Thread Vao Matua
Can someone help me understand two different types of stream and road
crossings?

A ford can be a node or a way
(180,749 nodes & 63,842 ways)

However, a culvert can
only be a way (691,972 ways)

In many circumstances from imagery I can see a stream crossing under a road
without a bridge or ford and therefore I assume that it is a culvert, but
typically cannot see the ends to split the watercourse.  Why does a culvert
have to be a way rather than a way OR a node?

What I would like to do is simply merge a node of the road and a node of
the stream and give it the tag tunnel=culvert (when I do this JOSM
complains)

In the case where a culvert carries a watercourse over a road then it would
make sense to create a way and layer=1

Any insights for this apparent inconsistency?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "building=college" tag missing from building key page

2017-12-08 Thread Vao Matua
On Thu, Dec 7, 2017 at 3:08 PM, Steve Doerr wrote:

   On 07/12/2017 18:31, Marco Boeringa wrote:

>  College, as Vao Matua also pointed out, usually refers to secondary
> school / high school age education
>

Not in the UK, I'm afraid. It tends to refer to adult education of one
form or another. Or else an alternative to school for 17-to-18-year-olds
('sixth-form college').

Steve,

My point was that the term College in *Samoa* refers to secondary school /
high school age education. Not a statement about the use in all countries,
thanks for helping me understand the UK meaning.
Presently I am an instructor at a tertiary education institution that is
called a college.
All this is to say that the term "college" like many other terms has varied
meanings to different people.

On Thu, Dec 7, 2017 at 3:08 PM, Steve Doerr <doerr.step...@gmail.com> wrote:

> On 07/12/2017 18:31, Marco Boeringa wrote:
>
>> College, as Vao Matua also pointed out, usually refers to secondary
>> school / high school age education
>>
>
> Not in the UK, I'm afraid. It tends to refer to adult education of one
> form or another. Or else an alternative to school for 17-to-18-year-olds
> ('sixth-form college').
>
> --
> Steve
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
> ___
> 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=college" tag missing from building key page

2017-12-07 Thread Vao Matua
In Samoa the term "College" refers to a secondary school also known as a
high school in other places.

It seems that building=yes plus amenity=university for the area around the
buildings would work for the college question.

Can someone explain why there isn't a landuse=education tag, or something
equivalent?

On Thu, Dec 7, 2017 at 7:48 AM, Martin Koppenhoefer 
wrote:

> 2017-12-07 13:53 GMT+01:00 Tom Pfeifer :
>
>> So what is the building type difference between building=school and
>> building=college when it consists of seminar/class rooms?
>>
>>
>
> yes, these seem to describe the same (maybe there are differences,
> according to the type of college and special rooms needed for this).
>
>
>
>> Similarly there is little difference between a building with classrooms
>> used for a primary school or a kindergarten.
>>
>
>
> if you speak about Germany, there are differences. Kindergartens are
> usually built cheaper, have a different structure, and I think it is mostly
> like this. Kindergartens don't need a space for the kids to go during
> breaks for example.
>
> 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] Feature Proposal - RFC - River Classification

2017-08-29 Thread Vao Matua
Christoph,

The Deva river is a great example, thanks.

On Tue, Aug 29, 2017 at 8:42 AM, Christoph Hormann  wrote:

> On Tuesday 29 August 2017, Ilya Zverev wrote:
> >
> > https://wiki.openstreetmap.org/wiki/Proposed_features/Rivers_Classifi
> >cation
>
> I originally thought i'd stay out of these discussions on importance
> tags for rivers (because in the end i don't think there is anything to
> be gained from it) but this is just too good an opportunity, in
> particular to ask a former Saint-Petersburg resident:
>
> So the Neva:
>
> https://en.wikipedia.org/wiki/Neva_River
> https://www.openstreetmap.org/relation/2811903
>
> should be tagged river=small?
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> 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 - River Classification

2017-08-29 Thread Vao Matua
Ilya,

This seems to make sense as a way to help differentiate rivers. It is also
good because in will work with intermittent=yes.
I have a couple of comments: 1) When a mapper is looking at a river to
trace in a localized area they know the river is big or small only by
looking at the width of the watercourse, not the length, 2) It seems that
there should be consideration given to the social and economic importance
of a river. There are many populations and even cities in Africa that are
dependent on rivers even though they may not meet your definition of
major/big or even small. 3) More than likely a major river should also have
a polygon that represents the area as well.

Perhaps just river=big and river=small are the only tags needed?

Thanks for your work.

Emmor
(Palolo)

On Tue, Aug 29, 2017 at 2:50 AM, Ilya Zverev  wrote:

> Hi everyone,
>
> After a proposal about waterways classification by Daniel Koć, I decided
> to make an alternative one. To me, using subjective values and criteria for
> classifying rivers is a better way, since it can work in any country
> regardless of the official classification. It could be adjusted for any
> country, like we do with the place=* tag. And it is inherently
> understandable by casual mappers.
>
> So I propose a river=* tag with the following values:
>
> * river=major for longest rivers
> * river=big for big rivers
> * river=small for all other rivers
>
> See the proposal page for details on these values and rationale:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/
> Rivers_Classification
>
> Thanks,
> Ilya
> ___
> 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] Forestry/logging

2017-04-10 Thread Vao Matua
I think this is a great solution.
It is not possible to over-estimate the amount of work and skill involved
in classification of imagery from any source. It is great for the OSM
community to think that we can map the streets of the world, it is a
different matter to map vegetation types.

Emmor

On Mon, Apr 10, 2017 at 10:49 AM, Michael Patrick 
wrote:

>
> Have you considered using landsat-8 or sentinel-2 to get current landcover
>> using the QGIS plugin Semi-Automatic Classification? Landviewer [1] has a
>> nice interface for finding imagery that is cloud free and of recent
>> vintage? The learning curve to landcover classification is a bit steep,
>> but
>> it should be sufficiently accurate for remote areas Clifford
>>
>
> Scandanavian Forest services already have extremely detailed web services
> to provide this information ... '*Many users want to see how much forest
> there is in a specified area, estimate its average age, and to see which
> tree species it contains. SLU Forest Map contains spatial information with
> a high degree of detail over most of Sweden's forestland. SLU Forest Map is
> based on a combination of data from the Swedish National Forest Inventory
> 
> and satellite data 
> ...  SLU Forest Map is available free of charge as either a download or
> within our web based GIS application.*'
>
> ... including delivery to *MineCraft* ...  ('Examples of the use of open
> geodata in Minecraft
> ')
> ... now that's Open Data!
>
> My guess is the permits for future operations are online also. Such an
> inventory is is a non-trivial task
> ,
> especially maintaining it.
>
> A better way to handle this would be a federated page that layers OSM and
> the forestry web service(s).
>
> Michael Patrick
> Data Ferret
> OSM Seattle
>
> ___
> 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] Forestry/logging

2017-04-10 Thread Vao Matua
Clifford,

You are correct, landuse is different from landcover.
I assume you are tagging farmland as landuse, not landcover.
The problem with landcover is that the currency and consistency of the
source information is critical and is very difficult in OSM.
The OSM tagging for landcover should have two additional *required* tags:
"source=" and "source:date=" .

Regards,

Emmor

On Mon, Apr 10, 2017 at 8:17 AM, Clifford Snow <cliff...@snowandsnow.us>
wrote:

>
> On Sun, Apr 9, 2017 at 8:50 PM, Vao Matua <vaoma...@gmail.com> wrote:
>
>> This is an interesting discussion.  As a tree farmer and professional
>> forester I am offended by the suggestion that a harvested area is different
>> landuse from areas that are in other stages of forest growth.
>> I understand the need to avoid current logging operations, but I would
>> say that crowd sourced mapping is not the place to get that information.
>> There are so many basic features missing from OSM, spending effort to
>> collect vegetative landcover seems like a lower need, especially
>> considering the fact that in a relatively short period of time the
>> vegetative signature will be different.
>>
>
> Palolo,
> Thank you for your input. If I understand you, landuse=forest is what the
> land is being used for while landcover is what's there. To get a Warin's
> point, if you want to know if the area was clearcut recently, we should be
> using landcover.
>
> We do have a lot of features that need added to OSM. But I always
> encourage new mappers to map what they like. Currently I have been adding
> farmland to my county. It helps tell the counties story. Farmland is just
> part of the story, a big part of the county is also logging. Right now I'm
> reluctant to just start adding forested areas until I learn more. Any
> suggestions on how we should be mapping forested areas would be
> appreciated.
>
> Best,
> Clifford
>
>
> --
> @osm_seattle
> osm_seattle.snowandsnow.us
> OpenStreetMap: Maps with a human touch
>
> ___
> 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] Forestry/logging

2017-04-09 Thread Vao Matua
This is an interesting discussion.  As a tree farmer and professional
forester I am offended by the suggestion that a harvested area is different
landuse from areas that are in other stages of forest growth.
I understand the need to avoid current logging operations, but I would say
that crowd sourced mapping is not the place to get that information. There
are so many basic features missing from OSM, spending effort to collect
vegetative landcover seems like a lower need, especially considering the
fact that in a relatively short period of time the vegetative signature
will be different.

Emmor Nile
Palolo

On Mon, Apr 10, 2017 at 1:55 AM, Clifford Snow 
wrote:

>
> On Sun, Apr 9, 2017 at 3:06 PM, Warin <61sundow...@gmail.com> wrote:
>
>>
>> I would also like to know when a harvest is planed, so I can avoid the
>> area when that is taking place (traffic, noise and dust).
>>
>> Where an area has been clear felled, replanted and is now thick.. they
>> usually do a selective harvest to thin it out and leave the best trees for
>> future harvest. So there may be a need to tag that too?
>>
>> Other crops of a long term nature? The ones I can think of are all tree
>> related e.g. sandalwood.
>>
>> Satellite imagery is not much use for this.
>
>
> Have you considered using landsat-8 or sentinel-2 to get current landcover
> using the QGIS plugin Semi-Automatic Classification? Landviewer [1] has a
> nice interface for finding imagery that is cloud free and of recent
> vintage? The learning curve to landcover classification is a bit steep, but
> it should be sufficiently accurate for remote areas. I live in an area that
> is next to forested areas that is constantly being clear cut - with only
> logging roads to show human involvement. Being in the US's Pacific
> Northwest, I have to look for late fall to get cloud free imagery.
>
> If you do consider using data you derive, you definitely need to discuss
> it on the import list as well as with your local community.
>
> Clifford
>
> [1] https://lv.eosda.com
>
>
> --
> @osm_seattle
> osm_seattle.snowandsnow.us
> OpenStreetMap: Maps with a human touch
>
> ___
> 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] "Neutral" language for objects in international areas

2017-04-07 Thread Vao Matua
I would suggest that in addition to the specific language tags (name:[]=)
that the name= tag follow the multilingual convention
https://wiki.openstreetmap.org/wiki/Multilingual_names

Esperanto / English / French / other

On Fri, Apr 7, 2017 at 3:28 AM, Stephan Knauss 
wrote:

> Use name:en for English, name:fr for French and so on. No "name" tag.
>
> Map renderer will pick up the right one. See the map of openstreetmap.de
> on how this can be done.
>
> Stephan
>
>
> On April 7, 2017 3:26:15 AM GMT+07:00, "Nelson A. de Oliveira" <
> nao...@gmail.com> wrote:
>>
>> Which is the most appropiated/neutral language for international
>> objects? (outside countries, in ocean, etc)
>>
>> For example: https://www.openstreetmap.org/changeset/47301187
>>
>> When I first created the Point Nemo
>> https://en.wikipedia.org/wiki/Pole_of_inaccessibility#Oceanic_pole_of_inaccessibility
>> object I left it with name and alt_name in English (as I considered it
>> "neutral"/international enough).
>>
>> But then it was changed to Esperanto (in the above changeset).
>>
>> While I like and believe in Esperanto, somehow I think that it's not
>> the most appropriated language there.
>> Somebody could even argue that Interlingua
>> https://en.wikipedia.org/wiki/Interlingua is as valid as Esperanto,
>> for example, and start changing such objects.
>>
>>
>> So what should we use for such cases, please?
>>
>> --
>>
>> 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