Re: [OSM-talk-fr] Facebook et MapBox sont dans un bateau

[Jean-Christophe Becquet]

Le 14/07/2020 à 18:29, osm.sanspourr...@spamgourmet.com a écrit :
> Certes la situation est un peu différente mais après avoir essayé
> (souvent avec succès) de récupérer les développeurs de bibliothèques et
> d'outil OpenSource (comme Dane Springmeyer ouVladimir Agafonkin), voici
> que MapBox continue sa politique de sortie du libre.
Bonjour,

Tu as raison d'en parler sur la liste.

Le dernier WeeklyOSM s'en était fait l'écho :

« Mapbox fait un pas de plus pour sortir de l’écosystème open source.
Les notes de publication des premières versions alpha de Mapbox GL
Native pour iOS 5.10 et Mapbox GL Native pour Android 9.3.0 mentionnent
qu’elles commencent à dépendre de dépendances non libres publiées sous
les conditions de service de Mapbox, et non d’une licence libre. Seuls
les clients Mapbox peuvent accéder à ces binaires. (via @RichardF sur
Twitter) »
https://weeklyosm.eu/fr/archives/13367
https://mobile.twitter.com/richardf/status/1280490225836277760

Pour moi la différence, c'est que dans le cas de Mapillary, on savait
déjà que le socle logiciel n'était pas libre. Comme j'ai pu le dire dans
la discussion en fin d'AG OSM-fr, je pense que c'est un sujet important
pour l'avenir de la communauté OpenStreetMap. Bien entendu Facebook,
MapBox et les autres font ce qu'ils veulent avec leurs logiciels mais
pour ma part, si un outil n'est pas libre, même s'il est plus performant
ou plus facile, je choisis de ne pas l'utiliser.

Est-ce que la fondation pourrait aider en soutenant des alternatives
libres aux logiciels concernés ?

Bonne journée

JCB
-- 
MOUSTIC - Mise en Œuvre des Usages Sociaux
des Technologies et de l'Intelligence Collective
Rendez-vous dans les Alpes du 2 au 5 août 2020
http://moustic.info

==APITUX : le choix du logiciel libre==

APITUX - Jean-Christophe Becquet
2 chemin du Tivoli - 04000 Digne-les-Bains
06 25 86 07 92 - j...@apitux.com - http://www.apitux.com
SIRET : 452 887 441 00031 - APE : 6202A

===

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-us] Importing data for Prince William County, VA

[Matthew Woehlke]

On 13/07/2020 17.46, Mateusz Konieczny via Talk-us wrote:

Jul 13, 2020, 20:29 by mwoehlke.fl...@gmail.com:

It is still required to use a separate account for manually audited changes?


Is it going to be "by comparing dataset X and OSM I found places to map roads 
that I added
using aerial images"? Or more of "manually copied and verified geometries from 
external dataset"?


So far, I've done a bunch of stuff (on my own account) using the GIS 
data more as a supplemental reference layer, i.e. I haven't 
*technically* imported anything (but *have* hand-added some roads and 
other features and hand-edited others).


At some point, I am likely going to need to do a mass import of 
buildings, and that almost certainly *will* be an import.


--
Matthew

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] access=private on driveways

[Jmapb]

On 7/14/2020 7:44 AM, Greg Troxel wrote:

Around me the norm is that residential driveways (98% of them) are not
signed no trespassing, but that it is considered reasonable to use them
if 1) you live there 2) you are delivering something 3) you are a guest
4) you are going there for some other reason widely considered legit,
like "I'm a new neightbor and saying hello".

It is not reasonable to just drive up them because you feel like it, get
out of your car, stand there for two minutes, get back in and leave.
That will typically result in someone calling the police.  If it were
access=yes, like a real road, that would still be odd, but not
actionable.

So I don't think access=permissive is proper for residential driveways
unless there is good reason to believe that.   It probably is a good fit
for private roads in neighborhoods that don't have a culture of no
trespassing signs where many people come and go.


I completely agree. Mappers should have a good and verifiable reason to
tag access=permissive on any road, and preferably they should record
what that reason is. I've seen situations where a driveway could
conceivably be tagged access=permissive, but it's rare.


As for access=private 'breaking' routing, this discussion feels very
much like tagging for the router, instead of tagging what is and fixing
the router.  If you are driving someplace and you have permission, then
it should be expected that you can use access=private ways to get to
your destination.  Humans konw this, and while most people wouldn't
randomly drive down other people's driveways, it's obvious that if you
are invited to a house it's ok to use their driveway.

So a router that does not allow use of access=private for a final
segment, by default, is broken.


Tagging for the router is definitely a cousin of tagging for the
renderer. But both the router and the renderer are useful for
maintaining map quality. If something breaks the default
openstreetmap.org map, it's worth some scrutiny. Same with something
that breaks OSRM.

And the full rule as I know it is "don't tag *incorrectly* for the
renderer." Ditto for the router. I would never suggest removing a
legitimate verifiable access=private tag just to make a particular route
work. But that doesn't mean that the router's behavior can't influence
tagging at all.


Suppose there is a house with a driveway that connects two roads with
the house in the middle, that's access=private.  A router should not use
that segment unless the destination is on that property.  That's why I
said that routers should allow a final segement of private, but not a
transition to private and a transition back.


This is the *exact* scenario that access=destination is designed for.
Routing software should allow a route to access=destination ways, but
never through them as a short cut.


Residential driveways around me are tagged access=private.  I think it's
wrong to change that.


And I feel exactly the same about access=private as I do about
access=permissive: Mappers should have a good and verifiable reason to
tag access=private on any road, and preferably they should record what
that reason is.

If mappers (or importers) have decided by fiat that all driveways should
be access=private, I believe they've done a disservice to the map and so
removing that tag is probably correct. If they're simply trying to
encode unsigned local law or custom, that's explicitly against the
community best practices. If they're pulling from a reliable
imports-list-approved open data source or tagging based on surveyed
signage, well then, high-fives all around.


I am really just saing that a driveway to a house should not be tagged
access=yes because a no trespassing sign cannot be seen.  That is a complete
violation of verfiability, becuase the mapper has zero evidence that
access should be yes.


Agreed. Mappers should have a good and verifiable reason to tag
access=yes. But don't conflate the absence of an access tag with an
explicit access=yes, even if software treats them the same.


B) the owner expects the normal social customs to be followed, of
useonly for invited guests, deliveries/etc. and actual neighborly
visits,and doesn't put a up a no trespassing sign because it's
prickly, notbecause they want random people doing random things ==>
access=private


Here we disagree. I believe access=private means permission is required
to legally use the way. Implied permission by social custom is not the
same thing. And in the real world, a driveway and a private road that
requires permission are very different. Those accustomed to ignoring the
"part of your route is on private roads" warning on their GPS because of
access=private driveways may find themselves in for a quite a shock when
they're confronted by an angry hunting club member on an access=private
road through the woods, where the public route would have taken 5
minutes longer if they hadn't turned left an hour ago but is now it's a
2-hour detour.


I can 

Re: [Talk-us] access=private on driveways

[Mike Thompson]

On Tue, Jul 14, 2020 at 5:46 AM Greg Troxel  wrote:


> So a router that does not allow use of access=private for a final
> segment, by default, is broken.
+1
Even if we go with the idea that driveways are not access=private unless
posted, there are some driveways that are posted, and people (delivery
people, service people, invited guests. etc.) will need to be routed to the
residences at the end of those driveways. The router should just give a
warning to the user, such as "the final nn miles/km of your route are on
private roads".

Mike
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-GB] Call to action: Translators needed

[Simon Poole]

On 14.07.2020 17:21, o...@poppe.dev wrote:
> ... again, your wording sounds like you don't trust the organizations further 
> that you could throw a rock and basically discard their efforts as those of 
> money-hungry, evil corporations that aren't interested in the humanitarian 
> aspect at all (Ablasshandel was a big thing in medieval times, I guess we 
> shouldn't go down that road).

I've never found the concept of trust when dealing with legal entities
of any kind useful. In any case the correct throwing distance would be
dropping the stone.

There is nothing wrong with being money hungry btw, leads to predictable
behaviour, and is less fickle than many other things.

>
> I know that I might be exaggerating, but in essence you're just lumping all 
> 20+ organizations together and ignore their individuality.

I'm just commenting on the involvement "in" OSM which is fairly uniform.
OK HOT seems to be pivoting now around globalizing its paid mapping
business, but that is maybe because they are wising up on the fact that
the ambulance chasing may have run its course as a funding mechanism.

In any case you should do your own research on the organizations, some
have very good reputation, say MSF, others less so.

>> A "Call to action" for MapSwipe translations just reiterates the same
>> concepts in the particular absurd situation were the issue  at hand
>> could have been resolved with a couple of minutes work at any time over
>> the last 5 years if the developers were even remotely interested in
>> cooperating with wider OSM instead of just sapping out some manpower.
> "Call to action" was _my wording_ and _my idea_ alone, nobody forced me to 
> word it that way, nor have I given it a second thought, so every criticism to 
> that reflects back to my action.
>
> If you think that the developing team could have just done/given thought "5 
> more minutes" (As a developer for 30+ years, I'm very sceptical of such 
> claims) to incorporate their project into the established areas, there's no 
> hinderance for you to get into contact (because you now know of the problem, 
> that's why nobody has done so earlier) with them, and provide an easy 
> solution to the absurdity of the situation that you see.

It essentially boils down to checking a couple of boxes in transifex and
sending an announcement out to the existing translators that there is a
new project available, and changing the base URL for the project in
whatever they use to automate translations now.

Numerous projects have done it in the past, really no big deal.

And I've suggested it to "Humanitarian" projects before (would have to
dig if it was specifically MapSwipe), but as with essentially all
"Humanitarian" software development there is essentially no cooperation
with any mainstream OSM work, which may have to do with funding, maybe not.

>
> You might have just had a bad day just like I had a couple of unpleasant 
> weeks, but I do not understand your reasoning for your reactions. That might 
> just be me and I might be completely in the wrong here, but I suggest we 
> leave it at that. 
>
> Kai

It is just experience vs. trust.

Simon


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Q3 2020 Quarterly project Cycle Infrastructure

[ael]

On Tue, Jul 14, 2020 at 09:30:00PM +0100, Adam Snape wrote:
> 
> this point if we're actually advocating the hitherto undocumented  usage of
> segregated=yes to mean 'cycleway is separate from main carriageway' because
> I suspect I'm not the only one whose been using it as per the wiki to show
> where bicycles and pedestrians have their own designated lanes within a
> shared use cycleway. We can't use both.

+1  (separate lanes for cycles & pedestrians)


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-ca] Pont Gouin Saint-Jean-sur-Richelieu, Révision relations routes vélo empruntant le Pont - Travaux 2020

[Pierre Béland via Talk-ca]

A noter que le nouveau pont comprend une piste à une voie côté nord et une 
piste à deux voies côté sud. J'ai vérifié aujourd'hui, ce qui confirme que les 
travaux ne sont complétés que pour la voie côté nord et la voie côté sud ne 
sera pas opérationnelle avant l'automne. Aucun accès à proximité sauf détours 
via rue Champliain. Un circuit temporaire emprunte la rue Champlain pour l'été 
2020. J'ai donc révisé les relations affectées tel que décrit ci-dessous.
Deviation de l'écluse 9 vers Rue Champlain et piste nord du Pont Gouin
- Relation : Route Verte 1 https://www.openstreetmap.org/relation/416115 - 
Relation : TCT   https://www.openstreetmap.org/relation/7633543
Déviation vers Rue Champlain jusqu'à rue Saint-Jacques, puis portion 1 vers de 
l'écluse 9, et portion 2 ver piste nord du Pont Gouin
- Relation : Champlain Bikeway / Route Champlain 
https://www.openstreetmap.org/relation/2328456
Déviation de intersection Rue Champlain / Saint-Jacques, puis  piste nord du 
pont  Gouin
- Relation : La Montérégiade https://www.openstreetmap.org/relation/2226211
Déviation vers Rue Champlain jusqu'à rue Saint-Jacques
- Relation : Route Verte 2 https://www.openstreetmap.org/relation/416124
Pierre 
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-GB] Q3 2020 Quarterly project Cycle Infrastructure

[Adam Snape]

I'm not saying it's terrible but as you note it's not exactly an optimum
example of good mapping.

Just as with roads, I tend to view cycleway surface tags as distinctly
optional/low priority where they confirm to the default of being asphalt
and of great importance where they deviate from that default.

The above are just personal niggles, but we really do need to beclear at
this point if we're actually advocating the hitherto undocumented  usage of
segregated=yes to mean 'cycleway is separate from main carriageway' because
I suspect I'm not the only one whose been using it as per the wiki to show
where bicycles and pedestrians have their own designated lanes within a
shared use cycleway. We can't use both.

Kind regards,

Adam

On Tue, 14 Jul 2020, 20:14 Gareth L,  wrote:

> I do have to say that surface info is very useful. A lot of cycleways have
> gravel sections and that can be no fun on, say, a Brompton bike with 16”
> wheels.
>
> Much like pavements, I’d start my focus on the details which are not what
> you might expect, like where a road doesn’t have a pedestrian walkway at
> all, or only on one side. Ultimately, it’s all useful data.
>
> The embankment example makes some sense to me, although that level of
> Cycle infrastructure (cycle superhighways) is seldom seen outside of the
> capital. Segregated and sidewalk tag seems redundant as the footpath is
> mapped as a separate way, but they were added at version 1 when the other
> data may not have been there?
>
> Gareth
>
> On 14 Jul 2020, at 19:49, Adam Snape  wrote:
>
> 
> Quite agree, whilst harmless oneway=no seems a bit OTT, as tbh does
> marking the surface on every single asphalt cycleway...
>
> I have utmost respect for cyclestreets but that tagging guidance does seem
> garbled at points
>
> Since when has the segregated=yes/no tag on a cycleway referred to the
> physical separation of cycle routes from the main carriageway rather than
> the separation of cycles and pedestrians on the cycleway?
>
> The given 'high quality' example of the Embankment cycleway (mapped as a
> separate way, not part of the road) looks a bit odd with foot=no,
> segregated=yes, sidewalk=right.
>
> Kind regards,,
>
> Adam
>
>
>
>
>
>
>
> On Tue, 14 Jul 2020, 13:05 Mateusz Konieczny via Talk-GB, <
> talk-gb@openstreetmap.org> wrote:
>
>> "Is it one-way? oneway=yes / oneway=no"
>> is it really a good idea to always include oneway=no?
>> I would consider it as kind of pointless to require
>> oneway tag to be always present
>>
>> I added some advertisement for StreetComplete
>> (I implemented for example bicycle_parking quests
>> as part of my plan for collecting bicycle-related data).
>> Feel free to reduce/move/remove them.
>>
>>
>> Jul 13, 2020, 20:25 by o...@live.co.uk:
>>
>> Hello,
>>
>>
>>
>> The UK quarterly project for Q3 2020 has been selected as Cycle
>> infrastructure.
>> https://wiki.openstreetmap.org/wiki/UK_2020_Q3_Project:_Cycling_Infrastructure
>>
>>
>>
>> Another topical one with cycling having increased take up as people have
>> avoided public transport or took advantage of the (for a while) quieter
>> roads.
>>
>>
>>
>> Best regards
>>
>> Gareth
>>
>>
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
>>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Q3 2020 Quarterly project Cycle Infrastructure

[Gareth L]

I do have to say that surface info is very useful. A lot of cycleways have 
gravel sections and that can be no fun on, say, a Brompton bike with 16” wheels.

Much like pavements, I’d start my focus on the details which are not what you 
might expect, like where a road doesn’t have a pedestrian walkway at all, or 
only on one side. Ultimately, it’s all useful data.

The embankment example makes some sense to me, although that level of Cycle 
infrastructure (cycle superhighways) is seldom seen outside of the capital. 
Segregated and sidewalk tag seems redundant as the footpath is mapped as a 
separate way, but they were added at version 1 when the other data may not have 
been there?

Gareth

On 14 Jul 2020, at 19:49, Adam Snape  wrote:


Quite agree, whilst harmless oneway=no seems a bit OTT, as tbh does marking the 
surface on every single asphalt cycleway...

I have utmost respect for cyclestreets but that tagging guidance does seem 
garbled at points

Since when has the segregated=yes/no tag on a cycleway referred to the physical 
separation of cycle routes from the main carriageway rather than the separation 
of cycles and pedestrians on the cycleway?

The given 'high quality' example of the Embankment cycleway (mapped as a 
separate way, not part of the road) looks a bit odd with foot=no, 
segregated=yes, sidewalk=right.

Kind regards,,

Adam







On Tue, 14 Jul 2020, 13:05 Mateusz Konieczny via Talk-GB, 
mailto:talk-gb@openstreetmap.org>> wrote:
"Is it one-way? oneway=yes / oneway=no"
is it really a good idea to always include oneway=no?
I would consider it as kind of pointless to require
oneway tag to be always present

I added some advertisement for StreetComplete
(I implemented for example bicycle_parking quests
as part of my plan for collecting bicycle-related data).
Feel free to reduce/move/remove them.


Jul 13, 2020, 20:25 by o...@live.co.uk:

Hello,



The UK quarterly project for Q3 2020 has been selected as Cycle infrastructure. 
https://wiki.openstreetmap.org/wiki/UK_2020_Q3_Project:_Cycling_Infrastructure



Another topical one with cycling having increased take up as people have 
avoided public transport or took advantage of the (for a while) quieter roads.



Best regards

Gareth

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Q3 2020 Quarterly project Cycle Infrastructure

[Adam Snape]

Quite agree, whilst harmless oneway=no seems a bit OTT, as tbh does marking
the surface on every single asphalt cycleway...

I have utmost respect for cyclestreets but that tagging guidance does seem
garbled at points

Since when has the segregated=yes/no tag on a cycleway referred to the
physical separation of cycle routes from the main carriageway rather than
the separation of cycles and pedestrians on the cycleway?

The given 'high quality' example of the Embankment cycleway (mapped as a
separate way, not part of the road) looks a bit odd with foot=no,
segregated=yes, sidewalk=right.

Kind regards,,

Adam







On Tue, 14 Jul 2020, 13:05 Mateusz Konieczny via Talk-GB, <
talk-gb@openstreetmap.org> wrote:

> "Is it one-way? oneway=yes / oneway=no"
> is it really a good idea to always include oneway=no?
> I would consider it as kind of pointless to require
> oneway tag to be always present
>
> I added some advertisement for StreetComplete
> (I implemented for example bicycle_parking quests
> as part of my plan for collecting bicycle-related data).
> Feel free to reduce/move/remove them.
>
>
> Jul 13, 2020, 20:25 by o...@live.co.uk:
>
> Hello,
>
>
>
> The UK quarterly project for Q3 2020 has been selected as Cycle
> infrastructure.
> https://wiki.openstreetmap.org/wiki/UK_2020_Q3_Project:_Cycling_Infrastructure
>
>
>
> Another topical one with cycling having increased take up as people have
> avoided public transport or took advantage of the (for a while) quieter
> roads.
>
>
>
> Best regards
>
> Gareth
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-at] OpenStreetMap in Österreichs Bildung und Lehre, Frage id 70000

[Andreas]

Am 13.07.20 um 22:42 schrieb Manuela Schmidt:
> Hallo,
> 
>> Vielleicht kannst Du mir aber helfen. Gibt es Arbeiten welche sich mit
>> dem Potential im Einsatz von OpenSource Software wie Fossgis, und
>> OpenStreetMap auseinandersetzen.
> Es gibt eine Vielzahl akademischer Arbeiten in diesem Bereich. Einfach
> z.B. hier https://scholar.google.com/ nach entsprechenden Schlagworten
> suchen. Dabei muss berücksichtigt werden, dass die meisten
> wissenschaftlichen Studien sehr kleine Teilbereiche untersuchen, die
> nicht notwendigerweise generalisiert werden können.
>

Über meine alte FH habe ich auch folgendes Suchservice für explizite
österreichische Publikationen entdeckt:
https://search.obvsg.at/primo-explore/search?query=any,contains,Open%20Source=hs-tab_scope=OBV_HS=OBV=0

>> Gerade im Kommunalen Bereich in dem ich arbeite, sehe ich aktuell
>> überhaupt keinen Einsatz von Open Source, da dies dort zugleich mit
>> Null! Unterstützung gleichgesetzt wird. Dabei kann man ja Open Source
>> Software, und Support vertraglich wunderbar voneinander trennen.
> 
> Tatsächlich gibt es in Österreich aber auch nicht viele Anbieter für
> professionellen OpenGIS-Support. Viele Firmen in diesem Bereich sind
> EPUs, was für große Institutionen dann teilweise zu heikel ist.
> Deutschland scheint mir in diesem Bereich besser aufgestellt zu sein.
>

Ja das kann ich bestätigen. Die großen Firmen, die nicht Open Source
Software anbieten haben ein extrem gutes Marketing und leisten außerdem
viel Lobbyarbeit, sodass sich Firmen die rein auf Open Source Software
sich spezialisiert haben sich schwer tun da mitzuhalten.

Meiner Meinung nach ist selbst in den Kommunen noch nicht der Nutzen von
Open Source Software angekommen. Die meisten wollen einen Vertrag mit
einer Firma und wo sie bei Problemen auf diese Firma sich beziehen
können. Da tut man sich bei OpenSource schwer bezüglich der Haftung.

Das funktioniert ja außerhalb des GIS Bereiches ja in den Kommunen auch
nicht. Wie viele Kommunen gibt es, die Linux als Betriebssystem
einsetzen oder LibreOffice statt Microsoft Office. Selbst die EU
verstößt hier gegen ihre Gesetze, weil es für die Verwaltung nur
Verträge mit Microsoft Partnern aushandelt und Alternativen erst gar
nicht in Betracht zieht.

Es wäre sicherlich schön, wenn OpenSource Software mehr im öffentlichen
Bereich eingesetzt werden würde, aber das braucht eine vernünftige
Planung und Wartung.

> Generell ist das Archiv der FOSSIS-Konferenzen
> [https://www.fossgis-konferenz.de] eine gute Fundgrube für
> Anwendungsbeispiele von OpenGIS auch bei Ämtern und Kommunen.
> 
>> Wäre es möglich eine Expertise über OpenSource als wissenschaftliche
>> Arbeit anzuregen.
> 
> Ich weiß nicht, was du damit meinst.
> 
> LG Manu
> 
> 
>>
>> Am Mo., 13. Juli 2020 um 09:45 Uhr schrieb Manuela Schmidt
>> mailto:manuela.schm...@tuwien.ac.at>>:
>>
>> Zumindest an der TU Wien (wo 2011 ja auch die SotM-Europe
>> veranstaltet wurde) sind Open Source Tools und offene Daten im
>> Geobereich ein wichtiger Bestandteil der Lehre.
>>
>> Auf https://catalogplus.tuwien.at/ kann nach Diplom- und
>> Masterarbeiten gefiltert werden, die an der TU zu dem Thema
>> veröffentlicht wurden.
>>
>> Und ja, auf talk-at lesen und schreiben auch Lehrende diverser
>> Hochschulen.
>>
>> LG Manu
>>
>>
>> Am 13.07.2020 um 07:05 schrieb Johann Haag:
>>>
>>> In Österreich gibt es 6 Hochschulen mit dem Studienfach
>>> Geographie und Kartographie.
>>> Diese Bildungseinrichtungen werden mit öffentlichem Auftrag
>>> betrieben, also auch vom Österreichischen Steuerzahler finanziert.
>>>
>>> Im Studienplan sollte sich auch daher, nicht nur kommerzielles
>>> sondern mehr oder weniger auch OpenSource und daher im weitesten
>>> Sinne auch OpenStreetMap finden.
>>>
>>> Gibt es irgendwo einen Spiegel an veröffentlichten Arbeiten, mit
>>> OpenStreetMap Bezug.
>>> Ich erwarte mir von Studenten keine Mapping Aktivität, es fällt
>>> mir aber schon auf, dass ich hiervon so rein gar nichts entdecke.
>>>
>>> Wie ist die Stimmung zu Open Source, in Österreichs
>>> Universitäten. Einen Lehrauftrag würde ich über die Steuergeld
>>> Finanzierung dieser Unis schon sehen. Hier im Mail Verteiler
>>> müssten sich jedenfalls an Geographie interessierte Lehrende finden.
>>>
>>> Siehe auch https://forum.openstreetmap.org/viewtopic.php?id=7
>>>
>>> Grüße Johann
>>>
>>>
>>> ___
>>> Talk-at mailing list
>>> Talk-at@openstreetmap.org 
>>> https://lists.openstreetmap.org/listinfo/talk-at
>> ___
>> Talk-at mailing list
>> Talk-at@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk-at
>>
>>
>>
>>
>> ___
>> Talk-at mailing list
>> 

Re: [OSM-legal-talk] OSM compatibility of licenses which restrict modification

[Kathleen Lu via legal-talk]

At least in English,
"not reuse the Information in a way that suggests that it is official or
that Licensor approves your use of the Information;
take all reasonable steps to ensure that the uses permitted above do not
mislead others and that the Information itself is not misrepresented."
reads as a trademark clause, which has always been okay and compatible.
-Kathleen

On Tue, Jul 14, 2020 at 8:42 AM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 14. Jul 2020, at 15:28, Mateusz Konieczny 
> wrote:
> >
> > Maybe they assume that it is covered
> > anyway by moral rights?
> >
> > But ODBL waives moral rights if allowed
> > by law,
> > it attempts to block asserting such claims,
> > and so on.
> >
> > Disclaimer: I am not a lawyer etc
>
>
> neither am I, just wondering up to which level contradictions and
> uncertainties in licensing terms are still ok for OpenStreetMap and when
> it’s too much.
>
> Cheers Martin
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk
>
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSRM-talk] Comparing routes from different datasets

[Florian Lohoff]

Hi Martin,

On Tue, Jul 14, 2020 at 05:07:04PM +0200, Martin Schmidl wrote:
> Hi,
> 
> In a project of mine I am using OSM data from a city for 7 different years.
> Recent data from 2020 acts as the reference. I want to see how different
> changes in the data will affect the routing for quality reasons (e.g: If i
> used data from 2014 today, will my route be better or worse?).
> 
> For this I am using OSRM on the 2020 data to get a reference route. I
> planned to check if the same route is possible in the older datasets from
> 2014 to 2019 (if the same route isn't possible, I am computing the route to
> the destination). I already tried to use some of the values from the
> reference route, however many values (like node IDs or locations) change
> over the different datasets and i can't really compare them to the original
> reference route. Maybe someone has already done something similar and can
> tell me what parameters were used from the routing result, i would really
> appreciate that.

I am doing route QA since 2013 on an hourly basis for a small part of
Germany. So i check whether predefined nodes (~1000) are still reachable
and if route distance and time have changed.
If it changes from dataset now() to now()-1 Hour i get an email
noting the routes which have changed.
I grouped the nodes into "clusters" which is more or less one
community/town/city so my any-2-any matrix does not get too large. Still
its about 60K routes every hour.

I have all routes or better the full OSRM result in a database and the
full geometry.

By this i try to find mapping errors of motorways, junctions etc on the 
high priority street network.

Mails contain a link which overlays both routes to a map e.g.:

https://osm.zz.de/routeqa/?rid=243864,251488#52.02004,8.53483,15z

Green is current and red is historic route. This was caused by a change
at "Jahnplatz" which is now closed for 2 years for construction.
If you click on the routes it shows distance and time.

This change caused about 400 routes to change because its an important
junction.

Most of the work is finding and maintaining the nodes. The cost/distance
of the network changes all the time so you have small changes here and
there. Sometimes you have nodes which have multiple paths which are
exactly the same time (Its fastest route - not shortest) so you have
flapping routes which you can only eliminate be disabling nodes in your
network.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


signature.asc
Description: PGP signature
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

[OSM-talk-fr] Facebook et MapBox sont dans un bateau

[osm . sanspourriel]

Certes la situation est un peu différente mais après avoir essayé
(souvent avec succès) de récupérer les développeurs de bibliothèques et
d'outil OpenSource (comme Dane Springmeyer ouVladimir Agafonkin), voici
que MapBox continue sa politique de sortie du libre.

On les avait déjà vus à l’œuvre privatisant les rendus vectoriels en
prétendant que leur d'attributs en couches était unique alors qu'il
était largement inspiré des couches osm.org avec les styles Mapnik.

Gaëlle avait dans sa présentation à Clermont-Ferrand avait d'ailleurs
dit que Michelin était reparti à zéro mais avait abouti grosso modo aux
mêmes couches.

Pour rappel MapBox doit beaucoup à OSM et sa fondation.

Mais pour le respect de l'esprit de la communauté OSM visiblement il
vaut mieux regarder de ce côté-ci de l'Atlantique.

Si certain•e•s peuvent envisager de candidater à la Fondation, ce serait
sans doute une bonne idée.

Jean-Yvon

https://weeklyosm.eu/fr/archives/13367

/Mapbox fait un pas de plus pour sortir de l’écosystème open source. Les
notes de publication des premières versions alpha de Mapbox //GL Native
pour iOS 5.10
//et
//Mapbox GL Native pour Android 9.3.0
//mentionnent
qu’elles commencent à dépendre de dépendances non libres publiées sous
les conditions de service de Mapbox, et non d’une licence libre. Seuls
les clients Mapbox peuvent accéder à ces binaires. (via //@RichardF
//sur
Twitter)/

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-legal-talk] OSM compatibility of licenses which restrict modification

[Martin Koppenhoefer]

sent from a phone

> On 14. Jul 2020, at 15:28, Mateusz Konieczny  wrote:
> 
> Maybe they assume that it is covered
> anyway by moral rights?
> 
> But ODBL waives moral rights if allowed
> by law,
> it attempts to block asserting such claims,
> and so on.
> 
> Disclaimer: I am not a lawyer etc


neither am I, just wondering up to which level contradictions and uncertainties 
in licensing terms are still ok for OpenStreetMap and when it’s too much.

Cheers Martin 
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [Talk-us] access=private on driveways

[Adam Franco]

On Tue, Jul 14, 2020 at 7:46 AM Greg Troxel  wrote:

> ...
>
> As for access=private 'breaking' routing, this discussion feels very
> much like tagging for the router, instead of tagging what is and fixing
> the router.  If you are driving someplace and you have permission, then
> it should be expected that you can use access=private ways to get to
> your destination.  Humans konw this, and while most people wouldn't
> randomly drive down other people's driveways, it's obvious that if you
> are invited to a house it's ok to use their driveway.
>
> So a router that does not allow use of access=private for a final
> segment, by default, is broken.
>

There is a big problem with this interpretation of tagging ways with
access=private that are not posted/gated to prevent access but are not used
by convention/norm: Doing this makes it impossible to distinguish these
from roads that *are* gated/posted.

As an example, a local airport has gated service roads and driveways
 to
get to a variety of maintenance and airline buildings. These are
appropriately access=private because they are gated and only employees can
use them. Routers need to be able to direct customers/public via the
close-by access=public/destination/customers roads and not try to use the
access=private roads. If access=private is used for most residential
driveways and routers need to treat access=private as a thing to be ignored
for final routing, they will get this airport situation wrong.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-gb-westmidlands] Black Country Geopark

[Brian Prangle]

Hi Andy and mappamercia

I've delved into this some more and it appears that the Geopark is a
collection of pre-existing sites so mapping them as a relation shouldn't be
too difficult. However the list of sites is published on the geopark
website with a
copyright claim so presumably we need to get explicit permission  to use
the list.(blackcountrygeop...@dudley.gov.uk). @Andy do you feel like
writing a nice diplomatic email to them?. I'll take a look at the UNESCO
resources to see if they have a copyright free list. Assuming we get a list
that's useable we could create a multipolygon for all the existing parks,
nature reserves that are included but there are a number of sites that
might be nodes - so how to include them?.

Proposed tagging
heritage=1
heritage:operator=UNESCO
operator= Black Country Geopark
boundary=protected_area
protect_class=3;98
protection_class= Global Geopark
start_date=2020-07-10
name= Black Country UNESCO Global Geopark
website=https://blackcountrygeopark.dudley.gov.uk/bcg

Interesting project for us to complete. Pity they have a google map to show
the extent of the geopark

Regards

Brian

On Mon, Jul 13, 2020 at 11:18 AM Brian Prangle  wrote:

> Hi Andy
>
> Great news that this has been achieved after the failure several years
> ago. Once we have the boundaries from a licence-compatible source I'm happy
> to complete this.
>
> Regards
>
> Brian
>
> On Sat, 11 Jul 2020 at 21:04, Andy Mabbett 
> wrote:
>
>> Do we have plans to map the new "Black Country Geopark":
>>
>>http://blackcountrygeopark.org.uk
>>
>>https://en.wikipedia.org/wiki/Black_Country_Geopark
>>
>> or to tag the various components as belonging to it? Is this suitable
>> for a "relation"?
>>
>> --
>> Andy Mabbett
>> @pigsonthewing
>> http://pigsonthewing.org.uk
>>
>> ___
>> Talk-gb-westmidlands mailing list
>> Talk-gb-westmidlands@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
>>
> ___
> Talk-gb-westmidlands mailing list
> Talk-gb-westmidlands@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
>
___
Talk-gb-westmidlands mailing list
Talk-gb-westmidlands@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands

[Talk-bo] visores de conjuntos de cambios en página osm.org

[Marco Antonio]

Hola,

Hace 1 mes aproximadamente escribí un script que añade el enlace de
los visores de conjuntos de cambios (achavi y osmcha) a las páginas en
osm.org de detalles de los elementos OSM (punto, línea, área), página
de historial, página de cambios de amigos, y página de ediciones de
usuarios

https://github.com/51114u9/osm-changeset-viewers

se tiene que instalar tampermonkey y luego activar el script, el
resultado es más o menos así:

https://raw.githubusercontent.com/51114u9/osm-changeset-viewers/master/osm-changeset-viewers_after.jpg

es muy útil para saber visualmente qué cambio introdujo un conjunto de
cambios en específico. Personalmente prefiero ACHAVI [1] a OSMCha [2]

Aún no funciona cuando se navega entre elementos sin abrir una nueva
pestaña en el navegador, pero se soluciona recargando la página :(.
Estoy investigando cómo resolver y parece que ya tengo la solución,
posible actualice a fin de semana

cualquier comentario o sugerencia hacerlo aquí →
https://github.com/51114u9/osm-changeset-viewers/issues

[1] https://wiki.openstreetmap.org/wiki/Achavi
[2] https://wiki.openstreetmap.org/wiki/OSMCha

Abrazos,

Marco Antonio

___
Talk-bo mailing list
Talk-bo@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-bo

Re: [Talk-GB] Call to action: Translators needed

[osm]

> I've been asked to clarify this as it might come across as a personal
> attack which was not intended, sorry.

Apology accepted, but ...

> The, very well funded, organizations in OSM space that claim
> "Humanitarian" for themselves, market themselves mainly by having a
> never ending stream of emergencies (some real, some not, some where OSM
> mapping could be useful, some not) that urgently need attention.
> 
> In exchange for allowing HOT, MM etc to monetize your participation in
> "resolving" these emergencies, you get alleviated to a superior human
> being, well at least for a while. Think of it as a digital Ablasshandel,
> just that in the middle ages the benefits were probably more tangible.

... again, your wording sounds like you don't trust the organizations further 
that you could throw a rock and basically discard their efforts as those of 
money-hungry, evil corporations that aren't interested in the humanitarian 
aspect at all (Ablasshandel was a big thing in medieval times, I guess we 
shouldn't go down that road).

I know that I might be exaggerating, but in essence you're just lumping all 20+ 
organizations together and ignore their individuality.

> A "Call to action" for MapSwipe translations just reiterates the same
> concepts in the particular absurd situation were the issue  at hand
> could have been resolved with a couple of minutes work at any time over
> the last 5 years if the developers were even remotely interested in
> cooperating with wider OSM instead of just sapping out some manpower.

"Call to action" was _my wording_ and _my idea_ alone, nobody forced me to word 
it that way, nor have I given it a second thought, so every criticism to that 
reflects back to my action.

If you think that the developing team could have just done/given thought "5 
more minutes" (As a developer for 30+ years, I'm very sceptical of such claims) 
to incorporate their project into the established areas, there's no hinderance 
for you to get into contact (because you now know of the problem, that's why 
nobody has done so earlier) with them, and provide an easy solution to the 
absurdity of the situation that you see.

You might have just had a bad day just like I had a couple of unpleasant weeks, 
but I do not understand your reasoning for your reactions. That might just be 
me and I might be completely in the wrong here, but I suggest we leave it at 
that. 

Kai

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[OSRM-talk] Comparing routes from different datasets

[Martin Schmidl]

Hi,

In a project of mine I am using OSM data from a city for 7 different years.
Recent data from 2020 acts as the reference. I want to see how different
changes in the data will affect the routing for quality reasons (e.g: If i
used data from 2014 today, will my route be better or worse?).

For this I am using OSRM on the 2020 data to get a reference route. I
planned to check if the same route is possible in the older datasets from
2014 to 2019 (if the same route isn't possible, I am computing the route to
the destination). I already tried to use some of the values from the
reference route, however many values (like node IDs or locations) change
over the different datasets and i can't really compare them to the original
reference route. Maybe someone has already done something similar and can
tell me what parameters were used from the routing result, i would really
appreciate that.

Best regards,
Martin
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [Talk-us] access=private on driveways

[Eric H. Christensen via Talk-us]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

‐‐‐ Original Message ‐‐‐
On Tuesday, July 14, 2020 10:15 AM, Matthew Woehlke  
wrote:

> The (possible) problem with having access implied by service=driveway is
> that a lot of access roads to stores/businesses/offices are also
> service=driveway... although I suppose you could argue these have the
> same semantics; you shouldn't be using them unless you're actually going
> to the location to which they provide access. (Which isn't to say that
> no one ever violates this...)

This ^^^ is, I believe, the crux of the matter.  Driveways shouldn't (or should 
rarely be) access=private as they are actually access=destination.  There are 
obvious times when you WANT someone to use your driveway.  Are there times to 
mark a highway=* as access=private?  Sure.  But I don't think driveways should 
be, by default, thought of as private when they are expected to be used by 
people with a valid need to access the property.  I believe that's what 
access=destination was designed for.  It works on driveways and it works on 
neighborhood streets in gated communities (keeps the router from trying to 
route through the neighborhood) if my understanding is correct (at least it's 
worked well for me).

R,
Eric "Sparks"
-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsFcBAEBCAAGBQJfDccYAAoJEIB2q94CS7PRBPMQAMxSnFlcZIkyCBUGT4Gf
U1n/O7OpZxDGSsNmWgD14xbJnOhQUuE75wWibnpioAnDTkSaxr+QuBLp9k/q
LDzezu7zIFIkZNGWtG0AopR1H9cHbWFX4MnjgObIxonIKsSAxEjGjhhJeSge
EfL8AE5CkcQQF8GWtqipnhQbWP+sIbrSfCdJKXiIbzfP6lXvAqUY0DPUQTsg
SFD2nFUYwIkcV88ez2tEvBjtIzwBh0gSboLe14/fRSyAT1nl5Y8YRxbsfyY0
Q7ilBSz8BMLXH52afhnPaARbf7usYu1JBUbASiLoCN4eKZwVxNasZzawsVG/
guRnUsSSPdkWmu5AtJ4DPStbp3PbvBYVEue6V9Y7XHzFLqBckkP4lvhxXzKo
n7A7Dga6i/l6aFAjyishAio4PzNqBk8LXOrXBQCjv4ChmKvJx96sGiXasz5V
TQ2BQbV1z5pdd19DmSPwfseYmpYP/1wWsjIWi1BxBUVZh0QPNVLj32x9uG4Q
FywjoR76EP59LS6wYinrxL5ndip42DevxRnKaG906lalQnEbwKlFpmsIg9bw
wO1fF8Mx9JOawcYlUiX0JLq59nzPdR38AXjfrFHshoOQs6Ynn8z3fZBPsIAF
R7nJaKT6rw3Uc0ONFgX6k3ApjYvEm0j8G9IkSHaM7Xmcgn7RTyvm8EWx6Uem
QeTd
=wdt9
-END PGP SIGNATURE-


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-GB] Call to action: Translators needed

[Simon Poole]

I've been asked to clarify this as it might come across as a personal
attack which was not intended, sorry.

The, very well funded, organizations in OSM space that claim
"Humanitarian" for themselves, market themselves mainly by having a
never ending stream of emergencies (some real, some not, some where OSM
mapping could be useful, some not) that urgently need attention.

In exchange for allowing HOT, MM etc to monetize your participation in
"resolving" these emergencies, you get alleviated to a superior human
being, well at least for a while. Think of it as a digital Ablasshandel,
just that in the middle ages the benefits were probably more tangible.

A "Call to action" for MapSwipe translations just reiterates the same
concepts in the particular absurd situation were the issue  at hand
could have been resolved with a couple of minutes work at any time over
the last 5 years if the developers were even remotely interested in
cooperating with wider OSM instead of just sapping out some manpower.

Simon

On 13.07.2020 00:59, Simon Poole wrote:
> It's the other way around, I believe you are the victim and have been had.
>
> Am 12. Juli 2020 21:12:15 MESZ schrieb Kai Michael Poppe - OSM
> :
>
> On 12.07.2020 20:58, Simon Poole wrote:
>
> The project in question could have naturally joined the
> OpenStreetMap transifex organisation and profited from a
> couple of 100 very experienced translators, but that would be
> too simple. 
>
>
> Well, don't kill the messenger. I myself only today discovered that 
> there's a JOSM team and an OSM organization.
> It might be worth checking whether the projects could be moved to the OSM 
> org.
>
> Kai
> 
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
>
> -- 
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit Kaiten Mail
> gesendet.
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-ie] Does OSM have a similar concept as the "Organisation" from Mappilary?

[Donal Hunt]

First I heard about it. I created teams for Cork and Ireland.

On Tue, 14 Jul 2020 at 15:14, moltonel 3x Combo  wrote:

> On 07/07/2020, Donal Hunt  wrote:
> > https://osmcha.org has a teams function which allows you to see changes
> > over time. See https://osmcha.org/teams
> > Pascal Neis also has some tools. e.g. you can visualise by hashtag here:
> >
> https://resultmaps.neis-one.org/osm-changesets?comment=osmirl#8/53.475/-8.015
> >
> > I quite like the missing maps leaderboard which can be found here:
> > https://www.missingmaps.org/leaderboards/#/osmirl (Kudos tshedy!!)
>
> Has https://dev.mapping.team/teams gained any traction ?
>
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ie
>
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [Talk-us] access=private on driveways

[Matthew Woehlke]

On 14/07/2020 09.44, Alex Hennings wrote:

Regarding:

a driveway to a house should not be tagged access=yes
because a no trespassing sign cannot be seen.  That is a complete
violation of verfiability, becuase the mapper has zero evidence that
access should be yes.

*Given our defaults, no access tag is equivalent> to that.*

You're saying *omitting* a tag violates *verifiability*. That doesn't
compute. Requiring tags to be verifiable with evidence specifically means
the opposite of that. But that might get us closer to the source of
disagreement. You and I interpret a *missing* access tag differently. *You
read a missing access tag to mean access=yes*. (Is there documentation to
support that somewhere? or... why do you think that?)


That's how iD represents it.

There is, of course, a solution to this... propose a new value with the 
appropriate semantics.


The (possible) problem with having access implied by service=driveway is 
that a lot of access roads to stores/businesses/offices are also 
service=driveway... although I suppose you could argue these have the 
same semantics; you shouldn't be using them unless you're actually going 
to the location to which they provide access. (Which isn't to say that 
no one ever violates this...)


--
Matthew

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-ie] Does OSM have a similar concept as the "Organisation" from Mappilary?

[moltonel 3x Combo]

On 07/07/2020, Donal Hunt  wrote:
> https://osmcha.org has a teams function which allows you to see changes
> over time. See https://osmcha.org/teams
> Pascal Neis also has some tools. e.g. you can visualise by hashtag here:
> https://resultmaps.neis-one.org/osm-changesets?comment=osmirl#8/53.475/-8.015
>
> I quite like the missing maps leaderboard which can be found here:
> https://www.missingmaps.org/leaderboards/#/osmirl (Kudos tshedy!!)

Has https://dev.mapping.team/teams gained any traction ?

___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

[Talk-cat] Estat de les vies (velocitat maxima)

[Xavier Barnada]

Hola llista,

He fet un repàs amb el overpass de les velocitats màximes a Catalunya  per
tindre una idea orientativa de com estan i es el següent:

*Tipus de via* *Elements sense maxspeed*
motorway 36
trunk 610
primary 5407
secondary 8424
tertiary 21527

Jo usant OpenStreetCam i Mapillary he pogut anar omplint les dades
d'algunes zones pero algunes altres requereixen imatges o coneixement local
per tal de completar aquesta informació.

Crec que aquesta informació és important per tal de poder realitzar bons
càlculs de rutes.

Salutacions
Xevi
___
Talk-cat mailing list
Talk-cat@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cat

Re: [Talk-it] Controllo coordinate dataset Biblioteche

[maurizio galli]

Per quelle che conosco nel Nord Milano sono spesso indicate le sedi vecchie
di almeno 10 anni.



Il mar 14 lug 2020, 15:02 Cascafico Giovanni  ha
scritto:

> Ciao,
>
> se qualcuno vuole fare qualche valutazione sulla precisione delle
> coordinate:
>
> http://u.osmfr.org/m/480434
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-us] access=private on driveways

[Alex Hennings]

Regarding:
> a driveway to a house should not be tagged access=yes
> because a no trespassing sign cannot be seen.  That is a complete
> violation of verfiability, becuase the mapper has zero evidence that
> access should be yes.
*Given our defaults, no access tag is equivalent> to that.*

You're saying *omitting* a tag violates *verifiability*. That doesn't
compute. Requiring tags to be verifiable with evidence specifically means
the opposite of that. But that might get us closer to the source of
disagreement. You and I interpret a *missing* access tag differently. *You
read a missing access tag to mean access=yes*. (Is there documentation to
support that somewhere? or... why do you think that?)

I read a missing access tag to mean access=unknown, and "we don't yet have
evidence of what the access restricts are" and "someone should find out and
add a tag" and "until then, *use your best judgement based on context,
because this is a service=driveway*". This opinion is supported by
service=driveway
documentation
: "There
is no defined default access tag for driveways".

A missing access tag surely needs to be interpreted based on context. For
example, consider a military base vs a playground. An explicit access tag
says "trust me, I have found evidence of this". We're discussing how to use
the access tag to describe a driveway, but that's solved with
service=driveway.

-Alex
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-it] Controllo coordinate dataset Biblioteche

[Andrea Musuruane]

Ciao,
nella mia zona, tranne qualche eccezione, le biblioteche sono
posizionati abbastanza male. Inoltre, sono presenti anche biblioteche
chiuse o trasferite da diverso tempo.

Ciao,

Andrea


On Tue, Jul 14, 2020 at 3:02 PM Cascafico Giovanni 
wrote:

> Ciao,
>
> se qualcuno vuole fare qualche valutazione sulla precisione delle
> coordinate:
>
> http://u.osmfr.org/m/480434
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-legal-talk] OSM compatibility of licenses which restrict modification

[Mateusz Konieczny via legal-talk]

14 Jul 2020, 14:54 by dieterdre...@gmail.com:

>
>
> sent from a phone
>
>
>> On 14. Jul 2020, at 12:40, Mateusz Konieczny via legal-talk 
>>  wrote:
>>
>> Such data is incompatible with
>> OSM requirements, must not be
>> imported, must be removed as
>> copyright violation if added already.
>>
>
>
> on the plus side there is a declaration of the license steward that the 
> license is compatible with the ODbL.
>
Maybe they assume that it is covered
anyway by moral rights?

But ODBL waives moral rights if allowed
by law,
it attempts to block asserting such claims,
and so on.

Disclaimer: I am not a lawyer etc___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [Talk-it] [Import] civici Bergamo

[Martin Koppenhoefer]

sent from a phone

> On 14. Jul 2020, at 14:48, Martin Koppenhoefer  wrote:
> 
> ho anche trovato un paper che lo dice:
> https://www.jlis.it/article/downloadSuppFile/5461/271


in realtà dice che è “probabilmente“ ok, visto la dichiarazione del license 
steward, per la IODL2, mentre per la IODL1 dice che nonostante la dichiarazione 
che derivated works sarebbero compatibili ci rimangono incertezze 
sull’“attribution stacking“


Ciao Martin ___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Cancelliamo gli opening_hours:covid19 ?

[Cascafico Giovanni]

Non per fare il menagramo, ma quando è stata decretata l'emergenza
c'erano molti meno casi di oggi ...e la discesa ha rallentato.

Il 14/07/20, Martin Koppenhoefer ha scritto:
>
>
> sent from a phone
>
>> On 14. Jul 2020, at 13:13, Francesco Ansanelli 
>> wrote:
>>
>> Gli orari di apertura covid andrebbero trasformati in orari di apertura o
>> assumi che sia tutto come prima?
>
>
> assumo che sia tutto come prima.
> Se pensate che avrebbe senso lasciare i tag un altro po’, potrebbe anche
> andare bene. non è detto che in una seconda fase gli orari saranno gli
> stessi.
>
> Ciao Martin
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-it] Controllo coordinate dataset Biblioteche

[Cascafico Giovanni]

Ciao,

se qualcuno vuole fare qualche valutazione sulla precisione delle coordinate:

http://u.osmfr.org/m/480434

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-legal-talk] OSM compatibility of licenses which restrict modification

[Martin Koppenhoefer]

sent from a phone

> On 14. Jul 2020, at 12:40, Mateusz Konieczny via legal-talk 
>  wrote:
> 
> Such data is incompatible with
> OSM requirements, must not be
> imported, must be removed as
> copyright violation if added already.


on the plus side there is a declaration of the license steward that the license 
is compatible with the ODbL.
I’ve found this document which indicates the compatibility is “likely ok”
https://www.jlis.it/article/downloadSuppFile/5461/271

licence in question is the IODL 1 and 2.


Cheers Martin ___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [Talk-it] [Import] civici Bergamo

[Martin Koppenhoefer]

sent from a phone

> On 11. Jul 2020, at 19:11, Martin Koppenhoefer  wrote:
> 
> non è questione della ODbL, la questione è il progetto OpenStreetMap, che 
> consente a chiunque di modificare tutto



in realtà sembra che sia problema della compatibilità con la Odbl, così hanno 
scritto in ml legal-talk e ho anche trovato un paper che lo dice:
https://www.jlis.it/article/downloadSuppFile/5461/271

Ciao Martin ___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Cancelliamo gli opening_hours:covid19 ?

[Martin Koppenhoefer]

sent from a phone

> On 14. Jul 2020, at 13:13, Francesco Ansanelli  wrote:
> 
> Gli orari di apertura covid andrebbero trasformati in orari di apertura o 
> assumi che sia tutto come prima?


assumo che sia tutto come prima. 
Se pensate che avrebbe senso lasciare i tag un altro po’, potrebbe anche andare 
bene. non è detto che in una seconda fase gli orari saranno gli stessi. 

Ciao Martin 
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Mapillary -> opensStreetCam

[Gad Jo]

Après essai la gestion des doublons est prisent en compte. Un message 
d'information indique que l'envoi est déjà prévu ou déjà fait.

J'ai tellement de séquences à envoyer que la file d'attente est longue mais 
d'autres tests doivent être fait.
J'ai constaté que si un envoi est déjà prévu et qu'on sélection plusieurs 
séquence pour demander un nouvel upload vers openstreetcam on peut retrouver 
plusieurs fois la même séquences en file d'attente... C'est ce cas là qui est à 
contrôler, normalement ça devrait être OK mais à vérifier...

Le July 11, 2020 7:52:48 PM UTC, Jacques Lavignotte  a 
écrit :
>Lu sur le foroum Mapillary :
>
>
>I made a tool to copy your images between Mapillary and OpenStreetCam: 
>https://osm.svimik.com/photosync/
>
>https://forum.mapillary.com/t/mapillary-openstreetcam-synchronization-tool/4246
>
>J.
>
>-- 
>GnuPg : 156520BBC8F5B1E3 Because privacy matters.
>« Quand est-ce qu'on mange ? » AD (c) (tm)
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Mapillary/Osmose/*signs

[Gad Jo]

Perso j'indique la limite sur la voie concernée. Pour le panneau et pour 
alléger les modifications pour le jour où les limites changent je m'abstient de 
créer les panneaux.

Prends le cas ou la vitesse est changée sur place et tu a les deux 
informations. Si tu en oubli une, un autre contributeur peut être tenter de 
corriger la bonne valeur par l'ancienne. Mettre les deux pourquoi pas mais 
autant limiter les informations redondante.

Le July 14, 2020 9:09:41 AM UTC, Jacques Lavignotte  a 
écrit :
>Bonjour,
>
>
>Je fais des capture d'itinéraires avec Mapillary.
>
>Quelques temps plus tard Osmose me propose les panneaux maxspeed / 
>maxweight.
>
>Autant que possible je reporte les restrictions sur la route.
>
>Mais j'en fais quoi de ces panneaux ?
>
>- posés sur le bord/dans le fossé ?
>
>- sur la way de la route ?
>
>- autre ?
>
>Merci, Jacques
>
>-- 
>GnuPg : 156520BBC8F5B1E3 Because privacy matters.
>« Quand est-ce qu'on mange ? » AD (c) (tm)
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] Q3 2020 Quarterly project Cycle Infrastructure

[Mateusz Konieczny via Talk-GB]

"Is it one-way? oneway=yes / oneway=no" 
is it really a good idea to always include oneway=no?
I would consider it as kind of pointless to require
oneway tag to be always present

I added some advertisement for StreetComplete
(I implemented for example bicycle_parking quests
as part of my plan for collecting bicycle-related data).
Feel free to reduce/move/remove them.


Jul 13, 2020, 20:25 by o...@live.co.uk:

>
> Hello,
>
>
>  
>
>
> The UK quarterly project for Q3 2020 has been selected as Cycle 
> infrastructure. >  
> https://wiki.openstreetmap.org/wiki/UK_2020_Q3_Project:_Cycling_Infrastructure
>
>
>  
>
>
> Another topical one with cycling having increased take up as people have 
> avoided public transport or took advantage of the (for a while) quieter roads.
>
>
>  
>
>
> Best regards
>
>
> Gareth
>
>

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-us] access=private on driveways (was: Deleting tiger:reviewed=no/addr:street for routes)

[Mateusz Konieczny via Talk-us]

Jul 14, 2020, 13:17 by jm...@gmx.com:

> On 7/14/2020 4:53 AM, Mateusz Konieczny  via Talk-us wrote:
>
>>
>> Jul 14, 2020, 02:20 by >> jm...@gmx.com>> :
>>
>>> If there was reason to believe you needed explicit  permission to 
>>> be on
>>> that way, then access=private would be correct.
>>>
>> I am unsure what is the best way to tag "explicit permissionnot 
>> required,
>> implicit permission is required" case. (it is not a bigproblem in 
>> Poland
>> where nearly all such roads will have a gate anyway, bumpingit 
>> into access=private)
>>
>
> I'm really not sure how to interpret "Implicit permission is  required." 
> To my mind, if permission is implicit, it's not  required 
> (access=permissive) and if permission is required, it's  not implicit 
> (access=private.)
>
>
You can go if you have a valid reason, even if not explicitly invited or 
permitted 
("hello, I am a new neighbor").

You are now allowed if you have no valid reason ("I used this road to make 
shortcut" or
"hello, I am a creepy stalker" or "hello, I am an onbnoxious peddler")
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] access=private on driveways

[Greg Troxel]

Tod Fitch  writes:

> There are “gated communities” where you can’t get in unless you have a
> card key or speak with a gate keeper. Those should, I think, have
> access=private as you need explicit permission on each entry.
>
> But for the case where the road is privately owned but the owner
> allows access without prior consent, access=permissive seems to be a
> good fit.

access=permissive is good when mappers know that the owner is ok with
people using the road.

access=yes is defined to mean that the public has a *right* of access.
A driveway to a a house very definitely does not meet that test.

Around me the norm is that residential driveways (98% of them) are not
signed no trespassing, but that it is considered reasonable to use them
if 1) you live there 2) you are delivering something 3) you are a guest
4) you are going there for some other reason widely considered legit,
like "I'm a new neightbor and saying hello".

It is not reasonable to just drive up them because you feel like it, get
out of your car, stand there for two minutes, get back in and leave.
That will typically result in someone calling the police.  If it were
access=yes, like a real road, that would still be odd, but not
actionable.

So I don't think access=permissive is proper for residential driveways
unless there is good reason to believe that.   It probably is a good fit
for private roads in neighborhoods that don't have a culture of no
trespassing signs where many people come and go.

As for access=private 'breaking' routing, this discussion feels very
much like tagging for the router, instead of tagging what is and fixing
the router.  If you are driving someplace and you have permission, then
it should be expected that you can use access=private ways to get to
your destination.  Humans konw this, and while most people wouldn't
randomly drive down other people's driveways, it's obvious that if you
are invited to a house it's ok to use their driveway.

So a router that does not allow use of access=private for a final
segment, by default, is broken.

(OSM's data model is not rich enough to label private with who has
permission when.  That's what is really needed to make this work.)

Suppose there is a house with a driveway that connects two roads with
the house in the middle, that's access=private.  A router should not use
that segment unless the destination is on that property.  That's why I
said that routers should allow a final segement of private, but not a
transition to private and a transition back.

Residential driveways around me are tagged access=private.  I think it's
wrong to change that.

I won't argue that tiger imported data gets this right.  I am really
just saing that a driveway to a house should not be tagged access=yes
because a no trespassing sign cannot be seen.  That is a complete
violation of verfiability, becuase the mapper has zero evidence that
access should be yes.  Given our defaults, no access tag is equivalent
to that.  If you can see it is a residential driveway and it is not
signed no trespassing, the two possibilities are:

  A) the owner is truly ok with random usage of the driveway *other than
  for legit purposes to visit or help the owner  ==> acesss=permisssive

  B) the owner expects the normal social customs to be followed, of use
  only for invited guests, deliveries/etc. and actual neighborly visits,
  and doesn't put a up a no trespassing sign because it's prickly, not
  because they want random people doing random things ==> access=private

  C is not a possibilty) The driveway is really legally a public way.
  (Well, anyone can be confused, but public way status can be looked up
  at town hall, making it entirely verifiable.)

When looking at such a driveway, one cannot tell for sure which is the
case of A and B.  But at least around me, it's 99.9% B, and thus "looks
like a residential driveway" is the verfiable backup for access=private.



I can certainly see a case for "access=destination" for these driveways,
with semantics that IF you have a reason to go to the house, you may use
the driveway.  But that's still access=private for the house and
arguably the land, and just moves things around in a way that I think
makes routing and data interpetation harder, and is thus a bad idea.

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [talk-cz] nečeský name=*

[Michal Fabík]

Ahoj,
eh, jo, pardon, v mezičase jsem to smazal, protože jako chorvatština to 
byl zjevný nesmysl. Vráceno tedy jako němčina.


BTW, tady[1] je z nějakého důvodu arabsky napsáno prostě "rovník", takže 
je otázka, jestli tyhle věci vůbec dávat do "name:xx", a ne třeba do 
"inscription:xx".


[1] 
https://cs.wikipedia.org/wiki/15._poledn%C3%ADk_v%C3%BDchodn%C3%AD_d%C3%A9lky#/media/Soubor:Jindrichuv_Hradec_15_polednik_pas.jpg




On 7/13/20 8:25 AM, Dalibor Jelínek wrote:


Ahoj,

já bych tipoval, že ta chorvatština bude spíše němčina, ne?

Dalibor




--
Michal Fabík


___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-us] access=private on driveways (was: Deleting tiger:reviewed=no/addr:street for routes)

[Jmapb]

On 7/14/2020 4:53 AM, Mateusz Konieczny via Talk-us wrote:


Jul 14, 2020, 02:20 by jm...@gmx.com:

On 7/13/2020 4:09 PM, Matthew Woehlke wrote:

On 13/07/2020 15.16, Kevin Kenny wrote:


The immediate curtilage of a house is presumed to be
private; at least
in the US, one does not drive or walk directly up to
someone's house
without having business there. (Someone making a delivery,
obviously,
has business there.)


...this seems to be the definition of access=destination?


I'd say yes, that access=destination is closest to how I interpret
most
driveways: you can walk/drive along the driveway if you have a good
reason, eg to make a delivery or an inquiry.

access=destination mean "no transit", not "with valid reason".

access=destination on driveway means "cannot be used by transit",
not "can be used if owner presumably agrees".

access=destination has the same meaning as access=yes on ways
that are not usable for transit (for example driveway attached to
a single road on one end and leading into house)


Yes, I believe I understand the distinction here. (Which is why I said
"closest" -- it's not exactly right.)

By my understanding, access=destination means "You may use this way if
this is your destination." There are three implications here:
1 - It's more permissive than access=private. You don't need to ask to
use this way.
2 - It's less permissive than access=yes/permissive. You *only* have
permission if this is your destination. (I said "a good reason" which is
not exactly the same thing, though close.)
3 - You may not traverse this way onto another way with different
access, ie, don't use it for a shortcut. (A common road sign for this in
the USA is "No Thru Traffic".)

When a dead end like a driveway is tagged with access=destination,
number 3 is irrelevant and from a routing point of view it's identical
to access=yes/permissive. But numbers 1 and 2 still apply, so from a
semantic point of view it's a little better IMO.

But as I said, I would not encourage anyone to start tagging all
driveways with access=destination. I believe it's usually a better fit
than access=private, but unless there's specific prohibitive signage I'd
recommend omitting access tags on driveways.


If there was reason to believe you needed explicit permission to be on
that way, then access=private would be correct.

I am unsure what is the best way to tag "explicit permission not required,
implicit permission is required" case. (it is not a big problem in Poland
where nearly all such roads will have a gate anyway, bumping it
into access=private)


I'm really not sure how to interpret "Implicit permission is required."
To my mind, if permission is implicit, it's not required
(access=permissive) and if permission is required, it's not implicit
(access=private.)

For a typical unsigned & ungated driveway in the USA, I'd describe the
implied access as "You may use this way to make a delivery, or to
immediately ring the doorbell and state your business."
Access=destination is the closest tag IMO, but I think just
service=driveway and no access tag is better.

Jason

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-it] Cancelliamo gli opening_hours:covid19 ?

[Francesco Ansanelli]

Ciao Martin,

Ti riferisci solo all'Italia, vero?
Gli orari di apertura covid andrebbero trasformati in orari di apertura o
assumi che sia tutto come prima?

Grazie
Francesco


Il mar 14 lug 2020, 11:02 Martin Koppenhoefer  ha
scritto:

> Come da oggetto, propongo un edit automatico per cancellare gli
> opening_hours:covid19=*
> (e forse altri tag covid19, se ci sono).
>
> Ciao
> Martin
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-legal-talk] OSM compatibility of licenses which restrict modification

[Mateusz Konieczny via legal-talk]

14 Jul 2020, 11:37 by dieterdre...@gmail.com:
> Can we guarantee that the contained information is not "misrepresented"?
>
No. ODBL has no such restrictions.

Therefore OSM data can be used in 
several evil or non-evil ways
that would violate such clauses.

Such data is incompatible with
OSM requirements, must not be
imported, must be removed as
copyright violation if added already.___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [Talk-es] Ediciones usuario JosefoLGV (o jlcc78)

[Miguel Sevilla-Callejo]

El usuario en cuestión fue bloqueado ayer para 6 meses:
https://www.openstreetmap.org/user_blocks/3799



On Mon, 13 Jul 2020 at 13:29, Miguel Sevilla-Callejo 
wrote:

> Hola,
>
> En su mensaje a esta misma lista de correo la persona que está detrás del
> usuario jlcc78 (José Sánchez) afirma [1]: "He sido bloqueado pero sigo
> trabajando en OSM."
>
> Es una verdadera pena que tengamos que estar con estas cuestiones,
> bloqueando usuarios y que haya personas que realicen ediciones de manera
> unilateral y sin consenso con la comunidad.
>
> Por cierto, José, si lees este correo verás que hemos reactivado el tema
> de Ceuta y Melilla y hay interés por parte de la comunidad que la situación
> sea resuelta.
>
> Saludos
>
> Miguel
>
> [1]
> https://lists.openstreetmap.org/pipermail/talk-es/2020-July/017351.html
>
>
>
> On Mon, 13 Jul 2020 at 12:13, xyg...@gmail.com  wrote:
>
>> Buenos días. Aquí un pequeño repaso de las ediciones “cáoticas" del
>> usuario JosefoLGV en la línea de las realizadas por el ahora bloqueado
>> jlcc78.
>>
>> https://www.openstreetmap.org/changeset/87891740
>> Aparte de cambiar el nombre de la N6, el título de su conjunto de cambios
>> lo dice todo: Ggle. name. Go and see
>>
>> https://www.openstreetmap.org/changeset/87890812
>> https://www.openstreetmap.org/changeset/87890831
>> https://www.openstreetmap.org/changeset/87890845
>> https://www.openstreetmap.org/changeset/87890874
>> En esta serie, se carga todo el nombre de la A52, lo cambia por la ref y
>> elimina las etiquetas en gallego, uno de los conjuntos de cambios se llama:
>> Castilian Highway
>>
>> https://www.openstreetmap.org/changeset/87891768
>> Esta es divertida, como nombre a una industria en Villardefrades le pone
>> Car cementery, se ve que prefiere el inglés para unas cosas y el castellano
>> para otras
>>
>> https://www.openstreetmap.org/changeset/87891602
>> https://www.openstreetmap.org/changeset/87891030
>> https://www.openstreetmap.org/changeset/87871343
>> Aquí vuelve con la carretera de “La Coruña”, y en algunos más también lo
>> cambia
>>
>> Hay más, pero creo que como muestra valen
>> Un saludo
>> Jesús
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-us] access=private on driveways (was: Deleting tiger:reviewed=no/addr:street for routes)

[Jmapb]

On 7/13/2020 3:22 PM, Tod Fitch wrote:

Out of curiosity, I looked at the tagging of a neighborhood I know of
which has privately owned roads (maintained by the homeowner’s
association) but no gate blocking entry. There are signs indicating
that the roads are “private” but that state road regulations are
enforced. The access on those roads is currently tagged as
access=permissive.

Thinking about it, that seems correct: The roads are privately owned.
But you are free to access them unless or until the owner withdraws
permission.

There are “gated communities” where you can’t get in unless you have a
card key or speak with a gate keeper. Those should, I think, have
access=private as you need explicit permission on each entry.

But for the case where the road is privately owned but the owner
allows access without prior consent, access=permissive seems to be a
good fit.

—Tod


Permissive sounds good to me in this case.

I suspect that sometimes access=permissive is applied in error by
mappers who misunderstand the term to mean "permission is required"
rather than "permission may be presumed."

To muddle things further, another popular tag is access=permit,
undocumented but I believe it means that access is allowed for holders
of a particular permit, eg, a camping permit or fishing license. If I'm
right about this then it's similar to access=private but a little more
informative.

And of course there's access=forestry, agricultural, military, delivery,
employees, customers -- all also a little more informative.

As usual I tag what I see, and if there's knowledge that can't easily be
observed firsthand then it's a good idea to be explicit about the source
and/or add a note=* tag. But I think this thread has made clear that
merely seeing the word "private" on a road sign does not mean the road
needs access=private.

Generally I'll use access=private for any road where the owner has
clearly prohibited unauthorized public access. A controlled physical
barrier isn't required but that would certainly qualify.

.Jason



___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[OSM-legal-talk] OSM compatibility of licenses which restrict modification

[Martin Koppenhoefer]

In recent local discussions it has emerged that some license has conditions
for the reuse of the data, which may eventually not be completely
compatible with OSM.

In particular it relates to an Italian license which states as a condition
you have to
"not reuse the Information in a way that suggests that it is official or
that Licensor approves your use of the Information;
take all reasonable steps to ensure that the uses permitted above do not
mislead others and that the Information itself is not misrepresented."

original text:
"non riutilizzare le Informazioni in un modo che suggerisca che abbiano
carattere di ufficialità o che il Licenziante approvi l'uso che fai delle
Informazioni;
prendere ogni misura ragionevole affinché gli usi innanzi consentiti non
traggano in inganno altri soggetti e le Informazioni medesime non vengano
travisate."


Can we guarantee that the contained information is not "misrepresented"?
IIRR, in the past we have rejected import plans where such discriminatory
clauses have been present in the license.

Cheers
Martin
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

[OSM-talk-fr] Mapillary/Osmose/*signs

[Jacques Lavignotte]

Bonjour,


Je fais des capture d'itinéraires avec Mapillary.

Quelques temps plus tard Osmose me propose les panneaux maxspeed / 
maxweight.


Autant que possible je reporte les restrictions sur la route.

Mais j'en fais quoi de ces panneaux ?

- posés sur le bord/dans le fossé ?

- sur la way de la route ?

- autre ?

Merci, Jacques

--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-it] Cancelliamo gli opening_hours:covid19 ?

[Martin Koppenhoefer]

Come da oggetto, propongo un edit automatico per cancellare gli
opening_hours:covid19=*
(e forse altri tag covid19, se ci sono).

Ciao
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-us] access=private on driveways (was: Deleting tiger:reviewed=no/addr:street for routes)

[Mateusz Konieczny via Talk-us]

Jul 14, 2020, 02:20 by jm...@gmx.com:

> On 7/13/2020 4:09 PM, Matthew Woehlke wrote:
>
>> On 13/07/2020 15.16, Kevin Kenny wrote:
>>
>>>
>>> The immediate curtilage of a house is presumed to be private; at least
>>> in the US, one does not drive or walk directly up to someone's house
>>> without having business there. (Someone making a delivery, obviously,
>>> has business there.)
>>>
>>
>> ...this seems to be the definition of access=destination?
>>
>
> I'd say yes, that access=destination is closest to how I interpret most
> driveways: you can walk/drive along the driveway if you have a good
> reason, eg to make a delivery or an inquiry.
>
access=destination mean "no transit", not "with valid reason".

access=destination on driveway means "cannot be used by transit",
not "can be used if owner presumably agrees".

access=destination has the same meaning as access=yes on ways
that are not usable for transit (for example driveway attached to 
a single road on one end and leading into house)

> If there was reason to believe you needed explicit permission to be on
> that way, then access=private would be correct.
>
I am unsure what is the best way to tag "explicit permission not required,
implicit permission is required" case. (it is not a big problem in Poland
where nearly all such roads will have a gate anyway, bumping it 
into access=private)
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] Des panneaux de direction

[Éric Gillet]

Le 19/06/2020 à 11:59, Jean-Christophe Becquet a écrit :

Bonjour,

Comment bien taguer ces points qualifiés par erreur comme panneaux
publicitaires alors qu'il s'agit de panneaux de direction ?

Les 2 premiers indiquent des quartiers ou des équipements structurants
pour la ville.
https://www.openstreetmap.org/node/1276519475
https://www.openstreetmap.org/node/1276520956
https://www.mapillary.com/app/?focus=photo=osqPf08fXanxs02gEepT2w=44.0894084=6.2294785=17=0.4845607940873434=0.47819761608877726=0.41570438799076215

  traffic_sign= ?


Pour ceux-là le formalisme est clair, ce sont des panneaux de direction 
routiers (moins sûr pour le Musée Gassendi). Je pense que le plus 
important est de mettre le tag destination="Centre Ville; etc" sur les 
voies, mais si tu tiens à mettre les nœuds panneaux il y a 
traffic_sign=FR:D21b


https://fr.wikipedia.org/wiki/Panneau_de_signalisation_directionnelle_de_position_en_France
https://wiki.openstreetmap.org/wiki/Key:traffic_sign#Lists_of_IDs_per_country


Le troisième indique des points d'intérêt : hôtel, camping, maison de
retraite, magasin
https://www.openstreetmap.org/node/4688783242
https://www.mapillary.com/app/?focus=photo=_XWVSbqnOLi-ugYdUCdLDA=44.089407=6.229187=17=0.30797704088175976=0.4262211197759842=2.0785219399538106

  tourism=information ?


C'est entre l'information pour touristes et la publicité, j'ai pas trop 
d'idées. Peut-être :


advertising=yes
message=tourism
tourism=information
information=guidepost
description=Panneau de direction pour établissements touristiques

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tagrequest :: "Nouveau lieu de loisirs et d’animations familiales"

[Éric Gillet]

Le 10/07/2020 à 13:36, Jacques Lavignotte a écrit :

Ce noeud

https://www.openstreetmap.org/node/7701888072

"Nouveau lieu de loisirs et d’animations familiales"

selon :

https://www.lanouvellerepublique.fr/vienne/a-biard-ce-soir-le-mana-ouvre-ses-portes-en-fanfare 



comme on y joue à la pétanque et qu'il y'a un panneau de basket j'ai 
mis « leisure=pitch » en attendant vos conseils avisés et que j'y 
aille ce soir boire une 


Comme toujours c'est compliqué les lieux à multi-usages sur OSM...

Là comme j'imagine que les "terrains" et la restauration ne sont pas 
exactement au même endroit, j'imagine deux nœuds ou zones, l'un pour la 
buvette/bar/resto, l'autre pour le(s) terrains. Les deux partageraient 
le même nom/opérator etc.



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-Talk-ZA] Hatfield, Pretoria - Add Shp File

[Reuben Honigwachs]

Hi Calayde,

have you seen the following advice already?
https://help.openstreetmap.org/questions/28829/upload-shapefile-to-osm

Best, Reuben

On Tue, 14 Jul 2020 at 09:45, Calayde Davey  wrote:

> Thank you,
>
> I am unfamiliar with the details - I will try my best this week, and reach
> back out to you if I have struggles.
>
>
>
> On Mon, 13 Jul 2020 at 15:37, Dave Coventry  wrote:
>
>> I'm not sure who would be required to authorise this, but I doubt that
>> anyone would have any objection.
>>
>> On Thu, Jul 9, 2020 at 2:58 PM Calayde Davey  wrote:
>> >
>> > Hello,
>> >
>> > I am working on African Digital Twin cities with University of Pretoria
>> & Chalmers, Sweden.
>> >
>> > May I have permission and guidance to upload building footprint shp
>> file for Hatfield precinct - Pretoria.
>> >
>> > Myself and my students will calibrate the file as we update and add
>> more information.
>> >
>> > --
>> >
>> > Kind regards,
>> > Calayde
>> >
>> > --
>> >
>> > Dr Calayde Davey
>> >
>> > MArch (UP-ZAR) PhD (KSTATE-USA)
>> >
>> > Post-Doctoral Research Associate - African Digital Twins
>> >
>> > STINT Program
>> >
>> > Department of Architecture, University of Pretoria
>> >
>> >
>> >
>> > Tel +06 065 22962
>> >
>> > Email u25106...@up.ac.za
>> >
>> >
>> > Faculty of Engineering, Built Environment and Information Technology
>> >
>> > Room 2-18, Boukunde Building, Hatfield Campus, University of Pretoria
>> >
>> > Private Bag X20, Hatfield 0028, South Africa
>> >
>> >
>> > This message and attachments are subject to a disclaimer.
>> > Please refer to
>> http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf for full
>> details.
>> > ___
>> > Talk-ZA mailing list
>> > Talk-ZA@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-za
>>
>> ___
>> Talk-ZA mailing list
>> Talk-ZA@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-za
>>
>
>
> --
>
> Kind regards,
> Calayde
>
> --
>
> Dr Calayde Davey
>
> MArch (UP-ZAR) PhD (KSTATE-USA)
>
> *Post-Doctoral Research Associate - African Digital Twins*
>
> STINT Program
>
> Department of Architecture, University of Pretoria
>
>
>
> Tel +06 065 22962
>
> Email u25106...@up.ac.za
> 
>
> Faculty of Engineering, Built Environment and Information Technology
>
> Room 2-18, Boukunde Building, Hatfield Campus, University of Pretoria
>
> Private Bag X20, Hatfield 0028, South Africa
>
> This message and attachments are subject to a disclaimer.
> Please refer to
> http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf for full
> details.
> ___
> Talk-ZA mailing list
> Talk-ZA@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-za
>
___
Talk-ZA mailing list
Talk-ZA@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-za

Re: [OSM-talk-fr] Best of OpenStreetMap : améliorer la page FR:Cartothèque sur le wiki

[osm . sanspourriel]

Bonjour,

Le site http://bestofosm.org ne répond plus.


Si, c'est juste le certificat qui a expiré depuis... mars.

Jean-Yvon



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] Mapping of Dover Harbour Board

[Jez Nicholson]

Thanks Frederik,

Looking on the positive side, it's nice to know that people out there want
our maps.

Regards,
   Jez

On Mon, 13 Jul 2020, 20:56 Frederik Ramm,  wrote:

> Hi,
>
> the DWG has received the following message:
>
> > Hi,
> >
> > A bit of feedback.
> > The openstreet map of Dover Harbour-UK has now become quite out of date.
> > Just wondering when it will receive an update after all the works done
> over the past 2 years with the Western Docks revival project and the new
> marina, quayside changes etc.
> >
> > Thanks,
> > (Name removed by F.R.)
>
> I'll reply that OSM is what its mappers make of it, and an invitation to
> contribute - but if anyone is familiar with the topic, perhaps this is
> an incentive to work on it.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[OSM-talk-fr] Best of OpenStreetMap : améliorer la page FR:Cartothèque sur le wiki

[Jean-Christophe Becquet]

Bonjour,

Le site http://bestofosm.org ne répond plus.

La page FR:Cartothèque sur le wiki OpenStreetMap qui propose de recenser
des exemples de qualité n'a pas été mise à jour depuis 2018.
https://wiki.openstreetmap.org/wiki/FR:Cartoth%C3%A8que

Je trouve très utile d'avoir sous la main une sélection de liens vers
des travaux exemplaires réalisés avec OSM.

Et je suis certain que vous avez des trésors à partager :
 - un site particulièrement bien cartographié
 - un rendu original qui met en avant la qualité des données
 - un zoom sur votre dernière cartographie de précision

Alors à vos contributions :-)
https://wiki.openstreetmap.org/wiki/FR:Cartoth%C3%A8que

Bonne journée

JCB
-- 
MOUSTIC - Mise en Œuvre des Usages Sociaux
des Technologies et de l'Intelligence Collective
Rendez-vous dans les Alpes du 2 au 5 août 2020
http://moustic.info

==APITUX : le choix du logiciel libre==

APITUX - Jean-Christophe Becquet
2 chemin du Tivoli - 04000 Digne-les-Bains
06 25 86 07 92 - j...@apitux.com - http://www.apitux.com
SIRET : 452 887 441 00031 - APE : 6202A

===

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Mapillary -> opensStreetCam

[Gad Jo]

J'ai testé cet nuit et ça fonctionne bien.

Par contre ce matin sur mon petit écran j'ai appuyé de nouveau sur upload. 
J'espère que ça ne va pas repartir en double.
Tu a des infos à ce sujet ?

Le July 11, 2020 7:52:48 PM UTC, Jacques Lavignotte  a 
écrit :
>Lu sur le foroum Mapillary :
>
>
>I made a tool to copy your images between Mapillary and OpenStreetCam: 
>https://osm.svimik.com/photosync/
>
>https://forum.mapillary.com/t/mapillary-openstreetcam-synchronization-tool/4246
>
>J.
>
>-- 
>GnuPg : 156520BBC8F5B1E3 Because privacy matters.
>« Quand est-ce qu'on mange ? » AD (c) (tm)
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr