Re: [Tagging] "Feature Proposal - RFC - Qanat"

[Joseph Guillaume]

Hi Martin,

Thanks for engaging!

I don't think it's appropriate to tag them all as historic=aqueduct. That
would be like tagging canals in Europe as historic just because they were
built a long time ago. There are active efforts to maintain and restore
qanats/kariz in Afghanistan that have been destroyed or neglected due to
fighting, and there's increased attention to the fact that pumping as an
alternative lends itself to overextraction of groundwater and high energy
use.

It's also very difficult to tell whether a qanat is operational or not from
aerial imagery, so in most cases without local knowledge it's safest to map
it based on its physical features, i.e. it is a qanat, and somebody else
needs to map whether it is historical or active.
If you consider that waterway=canal should only be used for active canals,
that would be a vote in favour of the more generic man_made=qanat, but
historic=aqueduct is not appropriate.

Cheers,

Joseph





On Sat., 20 Jun. 2020, 9:36 am Martin Koppenhoefer, 
wrote:

>
>
> sent from a phone
>
> On 20. Jun 2020, at 00:59, Joseph Guillaume 
> wrote:
>
> I just wanted to emphasise that this proposal isn't really about whether
> to tag qanats - it's about whether to tag them with man_made=qanat or
> waterway=canal+canal=qanat.
>
> There's already 1000 tagged, and they're very patchy geographically. It's
> quite likely there's upwards of 100,000
>
> It would be great to be able to formally deprecate man_made=qanat before
> it becomes de facto.
>
> Hopefully we can get enough interest in this issue for the vote to be
> convincing.
>
>
>
> The issue with waterway=qanat could be that it is only applicable to those
> structures that still carry water, while many of them will not be in a
> working state, or maybe I’m misguided?
>
> I could imagine using historic=aqueduct with a subtag aqueduct=qanat for
> all of them, and add the waterway tag to distinguish working from
> nonworking?
>
> I’ve found a short article about these in Bal‘harm, a city in Sicily which
> is now better known by its current name Palermo:
> http://www.bestofsicily.com/mag/art154.htm
>
> There’s a map that suggests there are really a lot of these underground
> tunnels, but the article also states that most aren’t in a working
> condition:
>
> In fact, fresh water still flows through some of the channels. Several
> were still in use well into the sixteenth century, long after the Arabs had
> melded into the general Sicilian population
>
>
> 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] Rail segment in a bike route

[Warin]

Normal OSM access is assumed to be access=yes, where some access is 
restricted then in OSM it should be marked *=no.


So where a train forbids bicycle transport then bicycle=no should be 
applied or some local default of bicycle=no on trains be documented.


Locally to me some trains require the bicycle to be boxed, but not all 
trains require this. None of this to my knowledge is OSM tagged here, 
many train routes have not been mapped in OSM so this detail is of a 
much lower priority.


On 19/6/20 10:33 pm, Peter Elderson wrote:
I think a bicycle route can not declare a rail route to be 
bicycle=yes. I think you should verify that the train is bicycle=yes 
before you call it a transfer. If it isn't, you can't declare it to be 
a part of your waymarked bicycle route, can you?


Apart from that, if a router uses the bicycle route relation, it 
should alway check the ways themselves for access, no matter what the 
route relation says.


Fr gr Peter Elderson


Op vr 19 jun. 2020 om 14:02 schreef Francesco Ansanelli 
mailto:franci...@gmail.com>>:


Dear Volker and Peter,

I agree with you both...
The question was born for a bike+train (funicular actually), but
it can be implemented in a generic way to fix similar cases.
Insead of interrupting the relation on the railway, we can put
the other public transport one as a member with a "transfer" role.
Of course, I assume the transfer relation will have 1 or 2 common
points with our trip (stops):
let's say a train starts from station A, but we take it at station
B with our bike, we get off at station C, but the last station
will be Z.
I don't think this could be an issue, but should be considered for
any future implementation.
Transfer relations should also consider the parent's relation type
(ex. route=bicycle, implies bicycle=yes on the train route).
What do you think?

Francesco

___
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 - Qanat"

[Martin Koppenhoefer]

sent from a phone

> On 20. Jun 2020, at 00:59, Joseph Guillaume  wrote:
> 
> I just wanted to emphasise that this proposal isn't really about whether to 
> tag qanats - it's about whether to tag them with man_made=qanat or 
> waterway=canal+canal=qanat.
> 
> There's already 1000 tagged, and they're very patchy geographically. It's 
> quite likely there's upwards of 100,000
> 
> It would be great to be able to formally deprecate man_made=qanat before it 
> becomes de facto.
> 
> Hopefully we can get enough interest in this issue for the vote to be 
> convincing.


The issue with waterway=qanat could be that it is only applicable to those 
structures that still carry water, while many of them will not be in a working 
state, or maybe I’m misguided?

I could imagine using historic=aqueduct with a subtag aqueduct=qanat for all of 
them, and add the waterway tag to distinguish working from nonworking?

I’ve found a short article about these in Bal‘harm, a city in Sicily which is 
now better known by its current name Palermo: 
http://www.bestofsicily.com/mag/art154.htm

There’s a map that suggests there are really a lot of these underground 
tunnels, but the article also states that most aren’t in a working condition:

> In fact, fresh water still flows through some of the channels. Several were 
> still in use well into the sixteenth century, long after the Arabs had melded 
> into the general Sicilian population
> 

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

[Tagging] "Feature Proposal - RFC - Qanat"

[Joseph Guillaume]

Hi all,

I just wanted to emphasise that this proposal isn't really about whether to
tag qanats - it's about whether to tag them with man_made=qanat or
waterway=canal+canal=qanat.

There's already 1000 tagged, and they're very patchy geographically. It's
quite likely there's upwards of 100,000

It would be great to be able to formally deprecate man_made=qanat before it
becomes de facto.

Hopefully we can get enough interest in this issue for the vote to be
convincing.

Thanks,

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

Re: [Tagging] "Feature Proposal - RFC - Qanat"

[Joseph Eisenberg]

> a spring is groundwater as well.

A spring is "a place where water naturally flows out from the ground". In a
spring, the water table reaches the surface.

The source of a qanat is underground, at least several meters depth (and
often quite far underground), below the underground water table. Sometimes
a well was dug first and then a qanat was built.

Please see the illustrations and examples on the Proposal page and
wikipedia, e.g:
https://en.wikipedia.org/wiki/Qanat#/media/File:Qanat_cross_section.svg

> if there are parts that are in pipes, will the qanat be interrupted? If
vertical shafts are not present, it is not a qanat (e.g. short enough to
not require these shafts)?

Qanats were not built from pipes. They are free-flow canals, usually cut
directly into bedrock, though that's not a requirement.

Currently, if a canal goes into a pipeline, it is standard practice to map
the pipeline as `man_made=pipeline` + `substance=water` and
perhaps `waterway=pressurised` if relevant. See for example
https://user-images.githubusercontent.com/42757252/76671649-dcce3980-65da-11ea-8dfb-55f9a21c1f12.png
- at https://www.openstreetmap.org/#map=17/41.70543/9.05265

>If vertical shafts are not present, it is not a qanat (e.g. short enough
to not require these shafts)?

The vertical shafts are part of the proposed definition.

If you check out some examples, you will see that the shafts are usually
only 10 to 50m apart, so even quite short qanat usually have more than 1.
E.g.:
https://www.openstreetmap.org/edit?way=624008315#map=17/31.43160/-4.36968 -
several parallel qanat are visible here (though I don't know if all are
still operational) in Morocco.

Examples in Afghanistan: https://overpass-turbo.eu/s/Vhk

>> The short definition of the tag will be "A gently-sloping man-made
underground channel for transporting groundwater via gravity, with shafts
visible from the surface."
> my suggestion would be to add a "typically" before "with shafts visible
from the surface", because it would seem strange to need a different main
tag just because the shafts aren't visible for one reason or the other
(e.g. hidden on purpose)

Sometimes there are small walls or caps over the shafts to prevent sand or
dirt from falling in. I was considering that to be still "visible" in a
way, but sure, we could change that.

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

Re: [Tagging] "Feature Proposal - RFC - Qanat"

[Martin Koppenhoefer]

Am Fr., 19. Juni 2020 um 23:15 Uhr schrieb Joseph Eisenberg <
joseph.eisenb...@gmail.com>:

> As mentioned on the proposal page, there are 4 criteria, which all qanat
> features share:
>
>
>- The immediate source of water is groundwater (aquifer or well), not
>a spring, stream or river
>
>

a spring is groundwater as well.



>
>- Water flows by gravity in free flow (not pressurized or pipe flow)
>- The channel is underground, minimising evaporation
>- Construction and maintenance is through vertical shafts, which are
>then visible on the surface
>
>

if there are parts that are in pipes, will the qanat be interrupted? If
vertical shafts are not present, it is not a qanat (e.g. short enough to
not require these shafts)?


>
> The short definition of the tag will be "A gently-sloping man-made
> underground channel for transporting groundwater via gravity, with shafts
> visible from the surface."
>


my suggestion would be to add a "typically" before "with shafts visible
from the surface", because it would seem strange to need a different main
tag just because the shafts aren't visible for one reason or the other
(e.g. hidden on purpose)

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

Re: [Tagging] "Feature Proposal - RFC - Qanat"

[Joseph Eisenberg]

> What about historic=aqueduct

The tag historic=aqueduct can be used, since it appears to be used for
underground aqueduct segments (as well as the more common above-ground
segments). It is briefly mentioned on the proposal page, but it is not part
of this proposal since it is an already accepted tag.

The tag will be used for currently functional canals. Generally these
features require occasional maintenance: while many were built decades ago,
the local villages maintain the knowledge and skills necessary to repair
and build these features. Brand-new qanat canals are rarely built since
powered pumps and pipelines are often cheaper to install.

> [Explain] what the criteria for the tag are (is this for all kinds of
underground aqueducts “in hot and arid” climate or are there specific
requirements for the term?)

As mentioned on the proposal page, there are 4 criteria, which all qanat
features share:


   - The immediate source of water is groundwater (aquifer or well), not a
   spring, stream or river
   - Water flows by gravity in free flow (not pressurized or pipe flow)
   - The channel is underground, minimising evaporation
   - Construction and maintenance is through vertical shafts, which are
   then visible on the surface


The short definition of the tag will be "A gently-sloping man-made
underground channel for transporting groundwater via gravity, with shafts
visible from the surface."

As mentioned on Wikipedia, these kinds of aqueducts/canals are also found
around the Mediterranean, as far as Spain, and from there they were also
brought to the Americas. But they are most commonly found in North Africa,
West Asia and Central Asia:
https://en.wikipedia.org/wiki/Qanat#/media/File:Qanat_technology_diffusion.svg


– Joseph Eisenberg

On Fri, Jun 19, 2020 at 1:42 PM Martin Koppenhoefer 
wrote:

> What about historic=aqueduct
> should it be applied as well, in case of historic qanats?
>
>
> 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 - Qanat"

[Martin Koppenhoefer]

What about historic=aqueduct
should it be applied as well, in case of historic qanats?


Cheers Martin 

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

Re: [Tagging] "Feature Proposal - RFC - Qanat"

[Martin Koppenhoefer]

sent from a phone

> On 19. Jun 2020, at 20:32, Joseph Eisenberg  
> wrote:
> 
> A qanat is a specialized kind of underground aqueduct which is the 
> traditional way of supplying water in hot and arid climates within limited 
> distance of a mountain range.


while the description reads quite neutral and inclusive, as if these features 
could occur everywhere on the globe, the term suggests it is very specific to a 
cultural region. Can you explain in what way these are “specialized”, what the 
criteria for the tag are (is this for all kinds of underground aqueducts “in 
hot and arid” climate or are there specific requirements for the term?). Is 
this only about historic features, or are there also modern qanats that get the 
tag? IMHO, if we want to include all kinds of underground aqueducts, something 
more generic would suit better, while I would be fine with tagging actual 
qanats as qanats.

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

Re: [Tagging] Adding mapillary tags to every building

[Alan Mackie]

On Fri, 19 Jun 2020 at 17:07, Cj Malone <
me-osm-tagg...@keepawayfromfire.co.uk> wrote:

> It's in Facebooks interest to have OSM be the best it possibly can.
> Facebook doesn't want to be dependant on Google for map data, so they
> are going to try and commoditise map data to improve competition.
>
> Google just released Google Maps SDK for Unity, an API for app
> developers to make Pokemon Go type games. OSM can't compete on that
> kind of ease of development. I think Facebook will come out with
> similar APIs to try and stop Google growing it's map data market share.
>
>
> How does Google's Unity SDK compare to the one that Mapbox offers?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] "Feature Proposal - RFC - Qanat"

[Joseph Eisenberg]

I have updated the existing proposal Qanat:
https://wiki.openstreetmap.org/wiki/Proposed_features/Qanat

A qanat is a specialized kind of underground aqueduct which is the
traditional way of supplying water in hot and arid climates within limited
distance of a mountain range. It consists of an underground gallery that
drains water from the aquifer at first (collection section) and then
channels it (transport section) along a gentle 1/1000 slope, with a series
of vertical shafts which are artifacts of the building process but also
serve for ventilation and service access, with an opening of the channel
section as it reaches the groundlevel and a further open air canal.
https://en.wikipedia.org/wiki/Qanat

This proposal would:

1) Approve the tag canal=qanat to be used with the existing tags
waterway=canal + tunnel=* to map the course of a qanat, defined as:

"A gently-sloping man-made underground channel for transporting groundwater
via gravity, with shafts visible from the surface."

2) Deprecate the duplicate tag man_made=qanat

That tag (man_made=qanat) has been used several hundred times, but it is
less appropriate to use the top-level feature tag "man_made" for a kind of
canal tunnel.

There is also discussion of a way to tag the qanat shafts as nodes: they
are vertical excavation and maintenance shafts along the course of the
watercourse which are currently mapped as man_made=excavation +
excavation=qanat_shaft.

This part could be removed from this proposal if it's debatable, but it
would be nice to approve a way to map the shafts as well, since they are
visible on survey and in aerial imagery.

Please comment here or at
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Qanat

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

Re: [Tagging] Adding mapillary tags to every building

[Mateusz Konieczny via Tagging]

Yes, I do no trust FB declarations at all, it FB still refuses to 
attribute OSM properly and I hope that FB employees will not be elected into 
OSMF board.

But in this case in FB self-interest is to keep this data available to OSM
and I expect that they will continue this.

Jun 19, 2020, 18:05 by me-osm-tagg...@keepawayfromfire.co.uk:

> It's in Facebooks interest to have OSM be the best it possibly can.
> Facebook doesn't want to be dependant on Google for map data, so they
> are going to try and commoditise map data to improve competition.
>
> Google just released Google Maps SDK for Unity, an API for app
> developers to make Pokemon Go type games. OSM can't compete on that
> kind of ease of development. I think Facebook will come out with
> similar APIs to try and stop Google growing it's map data market share.
>
> This is the iOS vs Android fight, except Google is Apple and Facebook
> is Google. Competition is a good thing.
>
>
>
>
> ___
> 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] Adding mapillary tags to every building

[Cj Malone]

It's in Facebooks interest to have OSM be the best it possibly can.
Facebook doesn't want to be dependant on Google for map data, so they
are going to try and commoditise map data to improve competition.

Google just released Google Maps SDK for Unity, an API for app
developers to make Pokemon Go type games. OSM can't compete on that
kind of ease of development. I think Facebook will come out with
similar APIs to try and stop Google growing it's map data market share.

This is the iOS vs Android fight, except Google is Apple and Facebook
is Google. Competition is a good thing.




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

Re: [Tagging] Rail segment in a bike route

[Francesco Ansanelli]

Dear Peter,

Maybe I wasn't so clear, but I agree with you, if the train is bicycle=yes
you can add it with "transfer" role in a bicycle route.

Cheers
Francesco

Il giorno ven 19 giu 2020 alle ore 14:35 Peter Elderson 
ha scritto:

> I think a bicycle route can not declare a rail route to be bicycle=yes. I
> think you should verify that the train is bicycle=yes before you call it a
> transfer. If it isn't, you can't declare it to be a part of your waymarked
> bicycle route, can you?
>
> Apart from that, if a router uses the bicycle route relation, it should
> alway check the ways themselves for access, no matter what the route
> relation says.
>
> Fr gr Peter Elderson
>
>
> Op vr 19 jun. 2020 om 14:02 schreef Francesco Ansanelli <
> franci...@gmail.com>:
>
>> Dear Volker and Peter,
>>
>> I agree with you both...
>> The question was born for a bike+train (funicular actually), but it can
>> be implemented in a generic way to fix similar cases.
>> Insead of interrupting the relation on the railway, we can put the other
>> public transport one as a member with a "transfer" role.
>> Of course, I assume the transfer relation will have 1 or 2 common points
>> with our trip (stops):
>> let's say a train starts from station A, but we take it at station B with
>> our bike, we get off at station C, but the last station will be Z.
>> I don't think this could be an issue, but should be considered for any
>> future implementation.
>> Transfer relations should also consider the parent's relation type (ex.
>> route=bicycle, implies bicycle=yes on the train route).
>> What do you think?
>>
>> Francesco
>>
>> ___
>> 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] Adding mapillary tags to every building

[Janko Mihelić]

Let's hope the license will be permissive enough for other projects to take
the data and continue their own way. They only said it will be free for
commercial use, but it didn't say free as in beer or what. They said:

> By continuing to make all images uploaded to Mapillary open, public, and
> available to everyone
>

Which is pretty vague.

pet, 19. lip 2020. u 13:42 Martin Koppenhoefer 
napisao je:

>
>
> sent from a phone
>
> > On 19. Jun 2020, at 11:20, European Water Project <
> europeanwaterproj...@gmail.com> wrote:
> > For how long ?
>
>
> for as long as Facebook wants. There is also the practical aspect: even if
> the license is permissive, it doesn’t imply you can actually get the data
> for downloading.
>
> Facebook has changed conditions of their services in the past, let’s
> recall their whatsapp acquisition where they promised it would remain
> “independent” from the rest of Facebook and where they then
> combined/unified their messenger services under the same hood some years
> later. If history has told us one thing, it’s not to trust facebook (IMHO
> not even as far as you’re able to throw them)...
>
> 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] Rail segment in a bike route

[Peter Elderson]

This

is
the talk page section I wrote about a week ago, for future consideration.

Fr gr Peter Elderson


Op vr 19 jun. 2020 om 14:33 schreef Peter Elderson :

> I think a bicycle route can not declare a rail route to be bicycle=yes. I
> think you should verify that the train is bicycle=yes before you call it a
> transfer. If it isn't, you can't declare it to be a part of your waymarked
> bicycle route, can you?
>
> Apart from that, if a router uses the bicycle route relation, it should
> alway check the ways themselves for access, no matter what the route
> relation says.
>
> Fr gr Peter Elderson
>
>
> Op vr 19 jun. 2020 om 14:02 schreef Francesco Ansanelli <
> franci...@gmail.com>:
>
>> Dear Volker and Peter,
>>
>> I agree with you both...
>> The question was born for a bike+train (funicular actually), but it can
>> be implemented in a generic way to fix similar cases.
>> Insead of interrupting the relation on the railway, we can put the other
>> public transport one as a member with a "transfer" role.
>> Of course, I assume the transfer relation will have 1 or 2 common points
>> with our trip (stops):
>> let's say a train starts from station A, but we take it at station B with
>> our bike, we get off at station C, but the last station will be Z.
>> I don't think this could be an issue, but should be considered for any
>> future implementation.
>> Transfer relations should also consider the parent's relation type (ex.
>> route=bicycle, implies bicycle=yes on the train route).
>> What do you think?
>>
>> Francesco
>>
>> ___
>> 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] Rail segment in a bike route

[Peter Elderson]

I think a bicycle route can not declare a rail route to be bicycle=yes. I
think you should verify that the train is bicycle=yes before you call it a
transfer. If it isn't, you can't declare it to be a part of your waymarked
bicycle route, can you?

Apart from that, if a router uses the bicycle route relation, it should
alway check the ways themselves for access, no matter what the route
relation says.

Fr gr Peter Elderson


Op vr 19 jun. 2020 om 14:02 schreef Francesco Ansanelli :

> Dear Volker and Peter,
>
> I agree with you both...
> The question was born for a bike+train (funicular actually), but it can be
> implemented in a generic way to fix similar cases.
> Insead of interrupting the relation on the railway, we can put the other
> public transport one as a member with a "transfer" role.
> Of course, I assume the transfer relation will have 1 or 2 common points
> with our trip (stops):
> let's say a train starts from station A, but we take it at station B with
> our bike, we get off at station C, but the last station will be Z.
> I don't think this could be an issue, but should be considered for any
> future implementation.
> Transfer relations should also consider the parent's relation type (ex.
> route=bicycle, implies bicycle=yes on the train route).
> What do you think?
>
> Francesco
>
> ___
> 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] Rail segment in a bike route

[Francesco Ansanelli]

Dear Volker and Peter,

I agree with you both...
The question was born for a bike+train (funicular actually), but it can be
implemented in a generic way to fix similar cases.
Insead of interrupting the relation on the railway, we can put the other
public transport one as a member with a "transfer" role.
Of course, I assume the transfer relation will have 1 or 2 common points
with our trip (stops):
let's say a train starts from station A, but we take it at station B with
our bike, we get off at station C, but the last station will be Z.
I don't think this could be an issue, but should be considered for any
future implementation.
Transfer relations should also consider the parent's relation type (ex.
route=bicycle, implies bicycle=yes on the train route).
What do you think?

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

Re: [Tagging] Adding mapillary tags to every building

[Martin Koppenhoefer]

sent from a phone

> On 19. Jun 2020, at 11:20, European Water Project 
>  wrote:
> For how long ?


for as long as Facebook wants. There is also the practical aspect: even if the 
license is permissive, it doesn’t imply you can actually get the data for 
downloading.

Facebook has changed conditions of their services in the past, let’s recall 
their whatsapp acquisition where they promised it would remain “independent” 
from the rest of Facebook and where they then combined/unified their messenger 
services under the same hood some years later. If history has told us one 
thing, it’s not to trust facebook (IMHO not even as far as you’re able to throw 
them)...

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

Re: [Tagging] Adding mapillary tags to every building

[European Water Project]

What leads you to believe that I am not calm ?

Have a nice day.

On Fri, 19 Jun 2020 at 11:40, Thibault Molleman 
wrote:

> Calm down.
> Normally if these images get their license upgraded to this newer license,
> normally it shouldn't be able to be reverted. But we'll see once they
> publish the license.
> (I don't really see a reason why Facebook would want to do that though
> tbh. Having Mapillary contain as much data as possible benefits them.)
> And yes, it's free. in exchange for nothing except a mention that it was
> from Mapillary.
> The whole 'problem' that facebook has, has nothing to do with this.
> it's not because a website uses Mapillary data that they need to implement
> cookies and other facebook crap
> Don't overreact..
>
> On Fri, 19 Jun 2020 at 11:20, European Water Project <
> europeanwaterproj...@gmail.com> wrote:
>
>> Hi Thibault,
>>
>> all the mapillary data is from now free to use, even for commercial
>> use : "Moving forward, that will continue to be true, except that starting
>> today, it will also be free to use for commercial users as well"
>>
>> For how long ?  and free in exchange for what --- the ability to place
>> cookies, track and target users/clients with advertisements & political
>> messages ?
>>
>> Best regards,
>>
>> Stuart
>>
>>
>>
>>
>>
>> On Fri, 19 Jun 2020 at 10:24, Thibault Molleman <
>> thibaultmolle...@gmail.com> wrote:
>>
>>> While I'm not a fan of Facebook either.
>>> If you play devils advocate. they have done some good stuff. and already
>>> notice some good changes to mapilary as well:
>>> - they have done some amazing work with 'map with AI'
>>> - all the mapillary data is from now free to use, even for commercial
>>> use : "Moving forward, that will continue to be true, except that starting
>>> today, it will also be free to use for commercial users as well"
>>> - and "This next chapter of Mapillary’s journey is an opportunity to
>>> build upon our OpenStreetMap efforts to a degree that was not possible
>>> earlier on. Previous OpenStreetMap development had to be balanced against
>>> development work for other mapping use cases. As part of Facebook, we can
>>> focus on OpenStreetMap while supporting Facebook’s open mapping efforts."
>>> Source: https://www.openstreetmap.org/user/jesolem/diary/393358
>>>
>>> So this (in theorie) could be a good thing
>>>
>>> On Fri, 19 Jun 2020 at 07:28, European Water Project <
>>> europeanwaterproj...@gmail.com> wrote:
>>>
 Hopefully a significant level of data openness will continue to be part
 of Mapillary's business model.



 yes, we can just hope for it. Not more.

 Just in case someone missed this, Mapillary has been acquired by
 Facebook yesterday...


 https://www.nytimes.com/reuters/2020/06/18/business/18reuters-facebook-deals-mapillary.html

 On Tue, Jun 9, 2020, 22:08 Andy Mabbett 
 wrote:

> On Mon, 8 Jun 2020 at 12:14, Janko Mihelić  wrote:
>
> > Photos of buildings are even more notable then photos of bicycle
> parking,
> > so I'll try and take photos of a few buildings and see how that goes.
> >
> > I probably won't be creating a category for each building, so then I
> will be
> > linking to those pictures with the image=* tag, right?
>
> You might like this tool:
>
>https://tools.wmflabs.org/wikishootme/
>
> which will tell you whether the buildings you photograph have an entry
> in Wikidata, and whether or not that entry has an image; if not, once
> you upload your image to Commons, you can also link to it from
> Wikidata.
>
> (Although it can be used as I describe above, its primary purpose is
> to find, for a given location, nearby Wikidata items that lack
> images.)
>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
>
> ___
> 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 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] Adding mapillary tags to every building

[Thibault Molleman]

Calm down.
Normally if these images get their license upgraded to this newer license,
normally it shouldn't be able to be reverted. But we'll see once they
publish the license.
(I don't really see a reason why Facebook would want to do that though tbh.
Having Mapillary contain as much data as possible benefits them.)
And yes, it's free. in exchange for nothing except a mention that it was
from Mapillary.
The whole 'problem' that facebook has, has nothing to do with this.
it's not because a website uses Mapillary data that they need to implement
cookies and other facebook crap
Don't overreact..

On Fri, 19 Jun 2020 at 11:20, European Water Project <
europeanwaterproj...@gmail.com> wrote:

> Hi Thibault,
>
> all the mapillary data is from now free to use, even for commercial
> use : "Moving forward, that will continue to be true, except that starting
> today, it will also be free to use for commercial users as well"
>
> For how long ?  and free in exchange for what --- the ability to place
> cookies, track and target users/clients with advertisements & political
> messages ?
>
> Best regards,
>
> Stuart
>
>
>
>
>
> On Fri, 19 Jun 2020 at 10:24, Thibault Molleman <
> thibaultmolle...@gmail.com> wrote:
>
>> While I'm not a fan of Facebook either.
>> If you play devils advocate. they have done some good stuff. and already
>> notice some good changes to mapilary as well:
>> - they have done some amazing work with 'map with AI'
>> - all the mapillary data is from now free to use, even for commercial use
>> : "Moving forward, that will continue to be true, except that starting
>> today, it will also be free to use for commercial users as well"
>> - and "This next chapter of Mapillary’s journey is an opportunity to
>> build upon our OpenStreetMap efforts to a degree that was not possible
>> earlier on. Previous OpenStreetMap development had to be balanced against
>> development work for other mapping use cases. As part of Facebook, we can
>> focus on OpenStreetMap while supporting Facebook’s open mapping efforts."
>> Source: https://www.openstreetmap.org/user/jesolem/diary/393358
>>
>> So this (in theorie) could be a good thing
>>
>> On Fri, 19 Jun 2020 at 07:28, European Water Project <
>> europeanwaterproj...@gmail.com> wrote:
>>
>>> Hopefully a significant level of data openness will continue to be part
>>> of Mapillary's business model.
>>>
>>>
>>>
>>> yes, we can just hope for it. Not more.
>>>
>>> Just in case someone missed this, Mapillary has been acquired by
>>> Facebook yesterday...
>>>
>>>
>>> https://www.nytimes.com/reuters/2020/06/18/business/18reuters-facebook-deals-mapillary.html
>>>
>>> On Tue, Jun 9, 2020, 22:08 Andy Mabbett 
>>> wrote:
>>>
 On Mon, 8 Jun 2020 at 12:14, Janko Mihelić  wrote:

 > Photos of buildings are even more notable then photos of bicycle
 parking,
 > so I'll try and take photos of a few buildings and see how that goes.
 >
 > I probably won't be creating a category for each building, so then I
 will be
 > linking to those pictures with the image=* tag, right?

 You might like this tool:

https://tools.wmflabs.org/wikishootme/

 which will tell you whether the buildings you photograph have an entry
 in Wikidata, and whether or not that entry has an image; if not, once
 you upload your image to Commons, you can also link to it from
 Wikidata.

 (Although it can be used as I describe above, its primary purpose is
 to find, for a given location, nearby Wikidata items that lack
 images.)

 --
 Andy Mabbett
 @pigsonthewing
 http://pigsonthewing.org.uk

 ___
 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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Adding mapillary tags to every building

[European Water Project]

Hi Thibault,

all the mapillary data is from now free to use, even for commercial use
: "Moving forward, that will continue to be true, except that starting
today, it will also be free to use for commercial users as well"

For how long ?  and free in exchange for what --- the ability to place
cookies, track and target users/clients with advertisements & political
messages ?

Best regards,

Stuart





On Fri, 19 Jun 2020 at 10:24, Thibault Molleman 
wrote:

> While I'm not a fan of Facebook either.
> If you play devils advocate. they have done some good stuff. and already
> notice some good changes to mapilary as well:
> - they have done some amazing work with 'map with AI'
> - all the mapillary data is from now free to use, even for commercial use
> : "Moving forward, that will continue to be true, except that starting
> today, it will also be free to use for commercial users as well"
> - and "This next chapter of Mapillary’s journey is an opportunity to build
> upon our OpenStreetMap efforts to a degree that was not possible earlier
> on. Previous OpenStreetMap development had to be balanced against
> development work for other mapping use cases. As part of Facebook, we can
> focus on OpenStreetMap while supporting Facebook’s open mapping efforts."
> Source: https://www.openstreetmap.org/user/jesolem/diary/393358
>
> So this (in theorie) could be a good thing
>
> On Fri, 19 Jun 2020 at 07:28, European Water Project <
> europeanwaterproj...@gmail.com> wrote:
>
>> Hopefully a significant level of data openness will continue to be part
>> of Mapillary's business model.
>>
>>
>>
>> yes, we can just hope for it. Not more.
>>
>> Just in case someone missed this, Mapillary has been acquired by Facebook
>> yesterday...
>>
>>
>> https://www.nytimes.com/reuters/2020/06/18/business/18reuters-facebook-deals-mapillary.html
>>
>> On Tue, Jun 9, 2020, 22:08 Andy Mabbett 
>> wrote:
>>
>>> On Mon, 8 Jun 2020 at 12:14, Janko Mihelić  wrote:
>>>
>>> > Photos of buildings are even more notable then photos of bicycle
>>> parking,
>>> > so I'll try and take photos of a few buildings and see how that goes.
>>> >
>>> > I probably won't be creating a category for each building, so then I
>>> will be
>>> > linking to those pictures with the image=* tag, right?
>>>
>>> You might like this tool:
>>>
>>>https://tools.wmflabs.org/wikishootme/
>>>
>>> which will tell you whether the buildings you photograph have an entry
>>> in Wikidata, and whether or not that entry has an image; if not, once
>>> you upload your image to Commons, you can also link to it from
>>> Wikidata.
>>>
>>> (Although it can be used as I describe above, its primary purpose is
>>> to find, for a given location, nearby Wikidata items that lack
>>> images.)
>>>
>>> --
>>> Andy Mabbett
>>> @pigsonthewing
>>> http://pigsonthewing.org.uk
>>>
>>> ___
>>> 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

Re: [Tagging] Adding mapillary tags to every building

[Thibault Molleman]

While I'm not a fan of Facebook either.
If you play devils advocate. they have done some good stuff. and already
notice some good changes to mapilary as well:
- they have done some amazing work with 'map with AI'
- all the mapillary data is from now free to use, even for commercial use :
"Moving forward, that will continue to be true, except that starting today,
it will also be free to use for commercial users as well"
- and "This next chapter of Mapillary’s journey is an opportunity to build
upon our OpenStreetMap efforts to a degree that was not possible earlier
on. Previous OpenStreetMap development had to be balanced against
development work for other mapping use cases. As part of Facebook, we can
focus on OpenStreetMap while supporting Facebook’s open mapping efforts."
Source: https://www.openstreetmap.org/user/jesolem/diary/393358

So this (in theorie) could be a good thing

On Fri, 19 Jun 2020 at 07:28, European Water Project <
europeanwaterproj...@gmail.com> wrote:

> Hopefully a significant level of data openness will continue to be part of
> Mapillary's business model.
>
>
>
> yes, we can just hope for it. Not more.
>
> Just in case someone missed this, Mapillary has been acquired by Facebook
> yesterday...
>
>
> https://www.nytimes.com/reuters/2020/06/18/business/18reuters-facebook-deals-mapillary.html
>
> On Tue, Jun 9, 2020, 22:08 Andy Mabbett  wrote:
>
>> On Mon, 8 Jun 2020 at 12:14, Janko Mihelić  wrote:
>>
>> > Photos of buildings are even more notable then photos of bicycle
>> parking,
>> > so I'll try and take photos of a few buildings and see how that goes.
>> >
>> > I probably won't be creating a category for each building, so then I
>> will be
>> > linking to those pictures with the image=* tag, right?
>>
>> You might like this tool:
>>
>>https://tools.wmflabs.org/wikishootme/
>>
>> which will tell you whether the buildings you photograph have an entry
>> in Wikidata, and whether or not that entry has an image; if not, once
>> you upload your image to Commons, you can also link to it from
>> Wikidata.
>>
>> (Although it can be used as I describe above, its primary purpose is
>> to find, for a given location, nearby Wikidata items that lack
>> images.)
>>
>> --
>> Andy Mabbett
>> @pigsonthewing
>> http://pigsonthewing.org.uk
>>
>> ___
>> 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