Re: [Tagging] Public Transport Timetables Proposal RFC

[Phake Nick]

Wasn't that only for the currently abandoned parts?

在 2019年2月12日週二 05:52，Jo  寫道：

> The proposal was voted upon.
>
> On Mon, Feb 11, 2019 at 9:54 PM Tijmen Stam  wrote:
>
>> On 31-10-18 00:54, Leif Rasmussen wrote:
>> > Hello everyone!
>> > I recently wrote up a proposal page for public transport schedule
>> data.
>> > This information would allow OpenStreetMap to store information about
>> > when or how often certain buses or trains arrive at a platform.
>> >
>> > https://wiki.osm.org/wiki/Proposed_features/Public_transport_schedules
>> >
>> > Please feel free to look over the page and give feedback.  I am very
>> > open to changing the proposal, so let me know if you have any ideas for
>> > improvements to it.
>> > Thanks,
>> > Leif Rasmussen
>>
>> On January 3rd this year, Leif added the "Interval" and "duration" tags
>> to the wiki for bus route:
>>
>> https://wiki.openstreetmap.org/w/index.php?title=Tag%3Aroute%3Dbus=revision=1767271=1684316
>>
>> I have sideways followed this discussion, but I had the idea there was
>> widespread opposition for having any timetable info added to OSM.
>>
>> I don't think we should have this on the wiki without proper proposal
>> voting - or did I miss something?
>>
>> ___
>> 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] tree rows vs individual trees

[Mark Wagner]

On Mon, 11 Feb 2019 15:55:50 +0200
Tomas Straupis  wrote:

>   Two things to add:
>   1. At least in Lithuania cartographic (topographic) "tree row" is
> defined as "a row of trees groing alongside a road or railway". That
> is random trees somewhere in a field do not become a "tree row" even
> if they are in a row.
>   2. If (1) is true in other countries, maybe "tree_row" should be an
> attribute of a road/railroad? Say
> highway=residential+tree_row=left|right|both. This way it would be
> much more convenient to create cartographically correct maps in 25k
> 50k scales without resorting to complex generalisation operations like
> displacement?
> 

Tree rows in the United States are usually planted as windbreaks.  As
such, they're usually either perpendicular to the prevailing winds, or
run along the edge of someone's property line.  Occasionally they're
planted for shade purposes, in which case they run east-west.  Tree
rows planted parallel to a road are uncommon.

"tree_row" as an attribute of a road might make sense, in the
same way as "sidewalk" tags do.  As a replacement for
"natural=tree_row", it excludes a lot of the existing uses.

-- 
Mark

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

Re: [Tagging] Co-ordinate sets vs. background informations = ODbL vs. CC

[Warin]

On 11/02/19 23:46, Ulrich Lamm wrote:

Am 08.02.2019 um 20:37 schrieb Ulrich Lamm:


OSM is already used like a quallity product.
We have to provide that quality, now, or we have to warn people that 
they should not use OSM until ten years later.


If / As official databases provide their contents under Creative 
Commons licenses to enable free use for everybody,

it is a lie to say, OSM cannot use them.

I have tried to show the way to prevent OSM from isolation by its own 
fault:
We have to distinguish between those contents (geometries), on which 
we cannot meet Creative Commons conditions,
and those contents (definitions, names, results of scientific 
investigations) on which we can meet Creative Commons conditions, easliy.


Let us face the background interests.

The problem of using official reference informations  that are 
available for free use
is not a problem between official databases and the community of 
volunteer mappers,
working for free on a collection of geographic informations that can 
be used for free.


It is a problem between the free community with its free product
and some people who exploit this free collection (and the unpaid work 
of thousands of volunteers) for commercial use.
Some people that hold powerful positions in the community live from 
selling applications of our volunteer work.
Certainly, some of these commercial applications are a surplus value 
in relation to the free applications.
But that is not our problem. Our intention is to get reliable free 
information as a revenue for free work.


If the most reliable informations are references that are excluded 
from commercial exploitation,
unless the exploiter has an individual license contract with the 
provider of the reference data,
the commercial exploiter has the choice either to sell a product 
without informations that are available for free,

or he has to pay.



Your method of including CC will mean not more use by commercial firms.

Here is a though for you.
Take OSM and combine with CC sources and then provide that as FSM (Free 
Street Map).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tree rows vs individual trees

[Graeme Fitzpatrick]

On Tue, 12 Feb 2019 at 07:28, Paul Allen  wrote:

> Or very tall grass.
>

All we need is Warin's lawn mower ^ - that'll fix 'em! :-)

Thanks

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

Re: [Tagging] Public Transport Timetables Proposal RFC

[Jo]

The proposal was voted upon.

On Mon, Feb 11, 2019 at 9:54 PM Tijmen Stam  wrote:

> On 31-10-18 00:54, Leif Rasmussen wrote:
> > Hello everyone!
> > I recently wrote up a proposal page for public transport schedule data.
> > This information would allow OpenStreetMap to store information about
> > when or how often certain buses or trains arrive at a platform.
> >
> > https://wiki.osm.org/wiki/Proposed_features/Public_transport_schedules
> >
> > Please feel free to look over the page and give feedback.  I am very
> > open to changing the proposal, so let me know if you have any ideas for
> > improvements to it.
> > Thanks,
> > Leif Rasmussen
>
> On January 3rd this year, Leif added the "Interval" and "duration" tags
> to the wiki for bus route:
>
> https://wiki.openstreetmap.org/w/index.php?title=Tag%3Aroute%3Dbus=revision=1767271=1684316
>
> I have sideways followed this discussion, but I had the idea there was
> widespread opposition for having any timetable info added to OSM.
>
> I don't think we should have this on the wiki without proper proposal
> voting - or did I miss something?
>
> ___
> 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] Proposed features - RFC - Power and pipeline substations functions

[François Lacombe]

HI all

The power and pipeline substations functions proposal is under RFC since
early January.
https://wiki.openstreetmap.org/wiki/Proposed_features/Substation_functions

Received comments on Talk page allow a few important improvements, here you
go for a concrete benefits summary
https://wiki.openstreetmap.org/wiki/Proposed_features/Substation_functions#Concrete_benefits

The vote will begin shortly if no further discussion starts over

All the best

François

Le dim. 30 déc. 2018 à 00:34, François Lacombe 
a écrit :

> Hi,
>
> I recently found out that current tagging for substations (power or
> pipelines) with substation=* key actually merge two distinct concepts.
> It deals with hierarchy levels and specific network functions a substation
> can host.
> It's hardly possible to document the substation=* key properly with the
> values voted in the last pipeline extension proposal.
> Main issue is a "compression substation" can also be a transmission or
> distribution substation and it hasn't been solved during the review process.
>
> I wrote a new proposal to move the less used values of substation=* in
> more detailed and dedicated functions subkeys.
> It also adds substation=generation (formerly substation=transmission) and
> substation=delivery which are missing currently.
> https://wiki.openstreetmap.org/wiki/Proposed_features/Substation_functions
>
> This not-so-big change on < 2000 existing objects (out of +300k power
> substations and 7k pipeline substations) would enable OSM to have a better
> matching with IEC definitions and a more usable tagging. We will be able to
> tag more objects with substation tagging (delivery substation mainly) than
> before.
> Most of function subkeys has defaults that allow us to add them on
> specific situations if required only.
>
> I'll add more example before vote start (surely next Febuary or March
> depending on how RFC goes)
>
> All the best
>
> François
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tree rows vs individual trees

[Paul Allen]

On Mon, 11 Feb 2019 at 20:54, Graeme Fitzpatrick 
wrote:

>
> Yep, you see similar rows quite frequently that have been planted like
> that, usually to form a wind break.
>

So they're not by the side of a road and they're not ornamental.  That
means that, although they
are trees and arranged in a row, they're not a tree row.  At least that's
how some here would
regard matters.  They're a hedge, or maybe scrub.  Or very tall grass.

"No true tree row" fallacy, anyone?

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

Re: [Tagging] man_made=storage_tank for open containers?

[Markus]

On Sun, 10 Feb 2019 at 23:48, marc marc  wrote:
>
> instead of creating a main tag value for each variety,
> I am as often in favor of dividing things into categories.
> if you are in front of a tank, man_made=tank
> after, you can add (sub)tags describing :
> - if a cover/roof exist or not
> - if its use is storage or an industrial process (e.g. sewage treatment
> plant basin)
> - if the content is clean water, dirty, fuel, corn...
> - if its underground, on the ground or half-half
> - whether it is inside a building or outside
> ...
>

That seems like a good idea to me.

Regards

Markus

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

Re: [Tagging] Public Transport Timetables Proposal RFC

[Tijmen Stam]

On 31-10-18 00:54, Leif Rasmussen wrote:

Hello everyone!
I recently wrote up a proposal page for public transport schedule data.  
This information would allow OpenStreetMap to store information about 
when or how often certain buses or trains arrive at a platform.


https://wiki.osm.org/wiki/Proposed_features/Public_transport_schedules

Please feel free to look over the page and give feedback.  I am very 
open to changing the proposal, so let me know if you have any ideas for 
improvements to it.

Thanks,
Leif Rasmussen


On January 3rd this year, Leif added the "Interval" and "duration" tags 
to the wiki for bus route: 
https://wiki.openstreetmap.org/w/index.php?title=Tag%3Aroute%3Dbus=revision=1767271=1684316


I have sideways followed this discussion, but I had the idea there was 
widespread opposition for having any timetable info added to OSM.


I don't think we should have this on the wiki without proper proposal 
voting - or did I miss something?


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

Re: [Tagging] tree rows vs individual trees

[Graeme Fitzpatrick]

On Tue, 12 Feb 2019 at 00:26, Ture Pålsson  wrote:

> However, I believe tree rows sometimes appear on their own. For example,
> the tree row in this
> picture (which was in the side bar of the Wiki for natural=tree_row) looks
> like it is not lining anything in particular:
>

Yep, you see similar rows quite frequently that have been planted like
that, usually to form a wind break.

Thanks

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

Re: [Tagging] man_made=storage_tank for open containers?

[Markus]

On Sun, 10 Feb 2019 at 23:28, Warin <61sundow...@gmail.com> wrote:
>
> On 11/02/19 07:31, Martin Koppenhoefer wrote:
>
> > I would have imagined a man_made=storage_tank to be a closed container, and 
> > would rather invent tags for open containers like man_made=slurry_pit,
>
> Too specific. [...]

I agree. Besides, i'd expect a slurry pit to be a hollow like [^1] or
[^2], not an open tank built on the surface like [^3].

[^1]: 
[^2]: 

[^3]: 

Regards

Markus

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

Re: [Tagging] Drain vs ditch

[Eugene Podshivalov]

пн, 11 февр. 2019 г. в 19:19, Hufkratzer :

> This would require to deprecate "drain" and remove it from the presets,
> otherwise we will continue to have 2 tags in the long run.  As far as I
> know deprecating a tag is only possible if it's usage declines. Currently
> its usage increases steadily. How do you intend to change that? What is the
> incentive for the mapper to use "ditch" instead of "drain" from now on? I
> am not even sure that most mappers will notice the change on the wiki
> pages.

In Belarus we have 45366 ditches and 93320 drains mapped. 90% of those
drains are drainage ditches (used for wet land drainage) because we have
swamps and wetlands everywhere.
You are right saying that the usage of "drain" increases, but as you see
from the statistics the usage is upside down because people perceive
"drainage ditches" and "drains" as one and the same thing. So why do we
need two tags for one and the same thing?

Cheers,
Eugene


пн, 11 февр. 2019 г. в 19:19, Hufkratzer :

> On 10.02.2019 14:57, Eugene Podshivalov wrote:
>
> [...}
> *Variant #2*
> Combine "ditch" and "drain" tags into one.
> [...}
> Personally I lean toward variant 2 [...}
>
>
> This would require to deprecate "drain" and remove it from the presets,
> otherwise we will continue to have 2 tags in the long run.  As far as I
> know deprecating a tag is only possible if it's usage declines. Currently
> its usage increases steadily. How do you intend to change that? What is the
> incentive for the mapper to use "ditch" instead of "drain" from now on? I
> am not even sure that most mappers will notice the change on the wiki pages.
>
> ___
> 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] tree rows vs individual trees

[Tomas Straupis]

2019-02-11, pr, 16:26 Ture Pålsson rašė:
> That possiblity already exists, as tree_lined=*. However, I believe tree
> rows sometimes appear on their own. For example, the tree row in this
> picture (which was in the side bar of the Wiki for natural=tree_row)
> looks like it is not lining anything in particular:

  But this is OSM wiki. What about "traditional" cartography? I
couldn't find "separate" tree row in topographic maps (last 150 years)
of Lithuania, but this could be because such feature is not popular on
the ground here.
  On the other hand, tree rows alongside roads/railroads/canals could
be mapped with attribute and separate ones with natural=tree_row
object.
  Individual trees would be very hard to use for such purpose - so
useless anyway.

> Byt yes, using tree_lined=* when appropriate certainly makes my life as
> a renderer developer easier, though I guess it is harder to combine with
> also mapping individual trees. :)

  You will probably skip trees on 25k or 50k? :-)

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

Re: [Tagging] Drain vs ditch

[Hufkratzer]

On 10.02.2019 14:57, Eugene Podshivalov wrote:

[...}
*Variant #2*
Combine "ditch" and "drain" tags into one.
[...}
Personally I lean toward variant 2 [...}


This would require to deprecate "drain" and remove it from the presets, 
otherwise we will continue to have 2 tags in the long run. As far as I 
know deprecating a tag is only possible if it's usage declines. 
Currently its usage increases steadily. How do you intend to change 
that? What is the incentive for the mapper to use "ditch" instead of 
"drain" from now on? I am not even sure that most mappers will notice 
the change on the wiki pages.


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

Re: [Tagging] tree rows vs individual trees

[Ture Pålsson]

2019-02-11 14:55 skrev Tomas Straupis:


2019-02-11, pr, 11:29 Ture Pålsson rašė:
[ ... ]
  2. If (1) is true in other countries, maybe "tree_row" should be an
attribute of a road/railroad? Say
highway=residential+tree_row=left|right|both. This way it would be
much more convenient to create cartographically correct maps in 25k
50k scales without resorting to complex generalisation operations like
displacement?


That possiblity already exists, as tree_lined=*. However, I believe tree 
rows sometimes appear on their own. For example, the tree row in this 
picture (which was in the side bar of the Wiki for natural=tree_row) 
looks like it is not lining anything in particular: 
https://upload.wikimedia.org/wikipedia/commons/thumb/6/69/Row_of_Poplar_Trees_-_geograph.org.uk_-_242206.jpg/200px-Row_of_Poplar_Trees_-_geograph.org.uk_-_242206.jpg


Byt yes, using tree_lined=* when appropriate certainly makes my life as 
a renderer developer easier, though I guess it is harder to combine with 
also mapping individual trees. :)



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

Re: [Tagging] tree rows vs individual trees

[Tomas Straupis]

2019-02-11, pr, 11:29 Ture Pålsson rašė:
> As someone who tries to render smallish-scale (typcally 1:25000 or
> 1:5) maps from OSM data, I am always slightly annoyed when someone
> states that something does not need to be mapped bacuse it can be
> inferred algorithmically from other data, without describing or at least
> giving a reference to such an algorithm.
>
> Tree rows -- real tree rows, i.e. a row of trees planted on purpose to
> function as a landscaping feature, not just some random trees which
> happen to be in a line -- are important landmarks and often show on maps
> as rows of green dots. However, the individual trees are typically too
> close to be shown at their real positions, so some generalization is
> required. Tagging the tree row provides such a generalization. I have no
> doubt that it is theoretically possible to synthesize tree-row objects
> from mapped trees, but I would guess that doing so with an acceptable
> number of false positives and negatives is close to a masters-thesis
> project.

  Exactly!

  Two things to add:
  1. At least in Lithuania cartographic (topographic) "tree row" is
defined as "a row of trees groing alongside a road or railway". That
is random trees somewhere in a field do not become a "tree row" even
if they are in a row.
  2. If (1) is true in other countries, maybe "tree_row" should be an
attribute of a road/railroad? Say
highway=residential+tree_row=left|right|both. This way it would be
much more convenient to create cartographically correct maps in 25k
50k scales without resorting to complex generalisation operations like
displacement?

-- 
Tomas

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

Re: [Tagging] Co-ordinate sets vs. background informations = ODbL vs. CC

[marc marc]

Le 11.02.19 à 13:46, Ulrich Lamm a écrit :
> exploit this free collection (and the unpaid work of thousands of 
> volunteers) for commercial use.

that's not a osm issue (osm have decided that's commercial use is 
allowed) and even less a problem for tagging where we discuss the most 
appropriate schemas to describe reality.

I don't know the link between your first message and this one,
but in your last message, your philosophical question is
"free as in free beer or as in freedom"
maybe the ml "talk" is a better place to talk about it.

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

[Tagging] Co-ordinate sets vs. background informations = ODbL vs. CC

[Ulrich Lamm]

Am 08.02.2019 um 20:37 schrieb Ulrich Lamm:

> OSM is already used like a quallity product.
> We have to provide that quality, now, or we have to warn people that they 
> should not use OSM until ten years later.
> 
> If / As official databases provide their contents under Creative Commons 
> licenses to enable free use for everybody,
> it is a lie to say, OSM cannot use them.
> 
> I have tried to show the way to prevent OSM from isolation by its own fault:
> We have to distinguish between those contents (geometries), on which we 
> cannot meet Creative Commons conditions,
> and those contents (definitions, names, results of scientific investigations) 
> on which we can meet Creative Commons conditions, easliy.

Let us face the background interests.

The problem of using official reference informations  that are available for 
free use
is not a problem between official databases and the community of volunteer 
mappers,
working for free on a collection of geographic informations that can be used 
for free.

It is a problem between the free community with its free product
and some people who exploit this free collection (and the unpaid work of 
thousands of volunteers) for commercial use.
Some people that hold powerful positions in the community live from selling 
applications of our volunteer work.
Certainly, some of these commercial applications are a surplus value in 
relation to the free applications.
But that is not our problem. Our intention is to get reliable free information 
as a revenue for free work.

If the most reliable informations are references that are excluded from 
commercial exploitation, 
unless the exploiter has an individual license contract with the provider of 
the reference data,
the commercial exploiter has the choice either to sell a product without 
informations that are available for free,
or he has to pay. 

Best regards
Ulrich Lamm

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

Re: [Tagging] tree rows vs individual trees

[Ture Pålsson]

2019-02-09 15:23 skrev Tom Pfeifer:

If a renderer wants to cluster any trees that can be done 
algorithmically.


As someone who tries to render smallish-scale (typcally 1:25000 or 
1:5) maps from OSM data, I am always slightly annoyed when someone 
states that something does not need to be mapped bacuse it can be 
inferred algorithmically from other data, without describing or at least 
giving a reference to such an algorithm.


Tree rows -- real tree rows, i.e. a row of trees planted on purpose to 
function as a landscaping feature, not just some random trees which 
happen to be in a line -- are important landmarks and often show on maps 
as rows of green dots. However, the individual trees are typically too 
close to be shown at their real positions, so some generalization is 
required. Tagging the tree row provides such a generalization. I have no 
doubt that it is theoretically possible to synthesize tree-row objects 
from mapped trees, but I would guess that doing so with an acceptable 
number of false positives and negatives is close to a masters-thesis 
project.


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