Re: [Talk-us] National Forest boundaries

[Bradley White]

> A relation for all would be ok too, as long as the private inholdings are
> not removed from the NF (which I think has been done in some cases).

I've argued for this in the past on this mailing list, but have since
come around to disagreeing with this position over tagging semantics.
Most NF boundaries are now tagged with 'boundary=protected_area', in
which case the boundary should represent physical land that the NF
actually owns and manages, and not the congressionally-declared
boundary. In my area, half of the city of Reno and nearly all of
Truckee fall within an congress-declared/administrative NF boundary -
these areas are certainly not protected.

IMO, a tagging scheme that better represents the meaning of these two
boundaries would be:
1. 'boundary=protected_area' around fee simple NF land ownership,
since this describes the actual protected areas of land
2. 'boundary=administrative' (with a not-yet-existing 'admin_level')
around declared NF boundaries, since this is an administrative
boundary for the NF and doesn't necessarily show what land is actually
managed by the NF.

We should even consider not including congressionally-declared
boundaries, since they aren't even theoretically verifiable on the
ground, and really don't necessarily indicate any kind of protection
of the land within the boundary. Fee simple ownership is at least
usually ground-verifiable with small yellow "NF boundary" placards.

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

[OSM-talk-fr] Nouveau dépliant OpenStreetMap chez Linux-Alpes

[Jean-Christophe Becquet]

Bonjour,

L'association Linux-Alpes qui porte le groupe OSM Digne a travaillé sur
un nouveau dépliant de présentation d'OpenStreetMap.
http://www.linux-alpes.org/depliant-openstreetmap/

Ce document petit format a été distribué en amont de la cartopartie des
commerces et services du centre ville organisée à Digne jeudi 18 juin.
http://www.linux-alpes.org/cartopartie-reussie-a-digne-les-bains/

Nous nous sommes efforcés de veiller au vocabulaire employé afin de
garder le contenu le plus accessible possible pour un public novice.
Dans un souci d'exemplarité, nous avons apporté une grande attention aux
mentions de crédits et de licences.

Afin de permettre sa réutilisation dans d'autres contextes, nous l'avons
réalisé intégralement avec des logiciels libres dont Inkscape pour la
mise en page. Nous partageons les sources sous licence libre Creative
commons BY-SA.

Nous encourageons donc les groupes locaux mais aussi les structures de
médiation numérique, les collectivités ou les entreprises qui souhaitent
contribuer à la promotion d'OpenStreetMap à reprendre et à adapter cette
ressource à leur contexte local et à la décliner selon leur thématique.

Pour notre part, nous envisageons par exemple d'illustrer la prochaine
version avec un rendu OpenTopoMap.
https://opentopomap.org/#map=14/44.09279/6.23603

Bien entendu, nous recevrons avec plaisir vos réactions et propositions
d'amélioration.


L'association Linux Alpes publie un #flyer @OSM_FR @openstreetmap sous
licence libre, recto-verso personnalisable pour vos événements locaux.
https://twitter.com/Linux_Alpes/status/1274362587006861312

Bonne journée

JCB
-- 
Utopie du logiciel libre
http://www.apitux.org/index.php?2008/05/29/247-utopie-du-logiciel-libre

==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] Labeling county roads (Idaho)

[Mark Wagner]

On Sun, 21 Jun 2020 21:45:19 +0900
tj-osmw...@lowsnr.net wrote:

> Newby here.
> 
> Started mapping an area of the Idaho panhandle around the Kootenai
> river. I notice that currently minor roads have a "County Road nn"
> name but TIGER2019 data also has names such as "Acacia Avenue". I
> think most map users would want to use the "Acacia Avenue" name as it
> what would be listed in postal addresses and they'd want to search it
> in applications such as OSMand. Question is how to handle this. Also,
> what to set the "ref" to for county roads.
> 
> There's not much information on the roads tagging page:
> 
> https://wiki.openstreetmap.org/wiki/United_States_roads_tagging#Individual_states_2
> 
> Proposal: use alt_name for "County Road nn" and name for "Acacia
> Avenue" where a name is given. (I've seen name_1 used but this is not
> really a "standard" OSM tag, AFAIK.)
> 
> For ref: set the ref to the county road number until someone can come
> up with a better proposal...
> 
> Any Idahoans have any information?

Not an Idahoan, but I've driven in the area from time to time.  The
roads I'm familiar with don't have a "County Road" designation on the
sign, just the road name.

-- 
Mark

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

Re: [Talk-us] National Forest boundaries (Mike Thompson)

[stevea]

On Jun 21, 2020, at 5:58 PM, Mike Thompson  wrote:
> 1) Not all "inholdings" are completely surrounded by the National Forest, 
> they are "bites" off the edge in some cases.  I don't think one can have an 
> inner ring and an outer ring which are at all coincident (they can't share an 
> edge) and still have a valid multipolygon.

I don't wish to sound dismissive as it seems we largely agree, but this is 
merely quibbling over constructing an outer edge.  If truly a "bite off the 
edge," then it seems the outer polygon should shrink to accommodate, no need 
for edge mumbo-jumbo (though sometimes these edge memberships take on a tagging 
life of their own and it gets to be a high-wire act as to how "loaded with 
tags" each one might become).  There are a lot of methods to capture semantics 
using syntax that is crisp and unambiguous, I believe some methods are smarter 
(less or even no ambiguity about the semantics that are "meant") and cleaner 
(fewer data) than others.  There is what might be characterized as "a wide zoo 
of tagging in these realms" (nationally at the enormous polygon scope).  Thank 
you (again) to Kevin for the word "menagerie" here.  This also enters what some 
have dubbed "higher math" (multipolygon edge tagging in a relational database 
and how deep these semantics can be relied upon are a "topology of deep genus").

> 2) Holes (inner rings) are not part of the polygon.  Thus if one did an 
> analysis of (for example) a series of points, any points that fall in one of 
> the holes would not register as being inside the multipolygon, even though 
> they are inside the outer ring.

That sounds right.

And a snappy-efficient way to achieve what is "truly excluded as PRIVATE" as an 
inner member of an "outer polygon that describes geographic extents of this 
PUBLIC forest" is by simply tagging what IS the inner member with "what it is." 
 That might seem fancy word salad, so I want to break down what we say as 
understandable to both of us.

We're using the double-duty that in a public forest (with a large, enclosing 
geography, but no larger than necessary or truly) which is tagged as outer 
role, anything we tag inner role is EXCLUDED from the public forest.  That 
"inholding," in every sense I've ever seen it, is private, hence, it's an inner 
to the outer, as private isn't public and vice versa.  The logic of opposites, 
the power of roles (inner and outer) in a relational database and the geography 
(in 2-space) of what we "mean" (quite intentionally) by inner and outer become 
powerful.  Let's simply tag the "thing inside, different from its enclosing 
polygon and so excluded from that polygon" for what it is, then include it as 
an inner member of the relation.  We do this, the logic of "nodes registering 
or not" is already built into "the space."  Think of a grassland in 
otherwise-land-filled-with-trees, it's a (mathematical) "hole" (of the 2-space, 
lat-long of nodes OSM lives in).  It simply works, like math, geography, 
software.

(Um, "well written" software!)

Meet you off list?

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

[OSM-talk-fr] Statistiques post-cartopartie

[Adrien André via Talk-fr]

Bonjour,

je suis à la recherche de ce qu'il est possible d'obtenir comme 
statistiques post-cartopartie (combien d'objets créés, total de longueur 
de voies, etc).


Il me semble avoir vu passer plusieurs fois le sujet, mais je ne me 
souviens plus dans quel canal et je ne trouve pas vraiment de doc là-dessus.


Par exemple avec OSMCha, on arrive à compter le nombre de changesets en 
filtrant sur des hashtags, mais pour l'instant je n'ai pas trouvé plus 
élaboré.


Auriez-vous plus d'infos ?

--
Adrien A.


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

Re: [Talk-us] National Forest boundaries (Mike Thompson)

[Mike Thompson]

Steve,

Perhaps I am not understanding what you are saying, but:

1) Not all "inholdings" are completely surrounded by the National Forest,
they are "bites" off the edge in some cases.  I don't think one can have an
inner ring and an outer ring which are at all coincident (they can't share
an edge) and still have a valid multipolygon.
2) Holes (inner rings) are not part of the polygon.  Thus if one did an
analysis of (for example) a series of points, any points that fall in one
of the holes would not register as being inside the multipolygon, even
though they are inside the outer ring.

Mike

On Sun, Jun 21, 2020 at 6:39 PM stevea  wrote:

> Continuing from my previous post, we even have an especially data-compact
> (efficient) way of representing that:  the member of the forest relation
> which is an inholding (tagged with role inner) IS the polygon of, say, a
> private residence "inside of" the forest.
>
> For example (I'm making this up), say we have a national forest with a
> small shopping area (for food, supplies...) near its center for
> convenience.  I could see one polygon (tagged landuse=retail, name=ABC
> Forest Shopping Center) both BEING exactly that, AND being included in the
> (enclosing) forest multipolygon as a member tagged "inner."  Voilà,
> double-duty and done.
>
> SteveA
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] National Forest boundaries (Mike Thompson)

[stevea]

Continuing from my previous post, we even have an especially data-compact 
(efficient) way of representing that:  the member of the forest relation which 
is an inholding (tagged with role inner) IS the polygon of, say, a private 
residence "inside of" the forest.

For example (I'm making this up), say we have a national forest with a small 
shopping area (for food, supplies...) near its center for convenience.  I could 
see one polygon (tagged landuse=retail, name=ABC Forest Shopping Center) both 
BEING exactly that, AND being included in the (enclosing) forest multipolygon 
as a member tagged "inner."  Voilà, double-duty and done.

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

Re: [Talk-us] National Forest boundaries (Mike Thompson)

[stevea]

Mike Thompson  wrote:
> One polygon for the administrative boundary of the NF which was established 
> by Congress.
> Zero or more polygons describing limitations on access (no need for polygons 
> to for access=yes, we can assume that in a NF generally), whether they be due 
> to private ownership, or other reasons.  
> The above are two separate concepts, so it is ok to have two separate OSM 
> elements, in my opinion.   
> A relation for all would be ok too, as long as the private inholdings are not 
> removed from the NF (which I think has been done in some cases).

If I'm not mistaken, we already have the machinery to do that with how we build 
multipolygons.  To wit, a single multipolygon (well tagged as to name of 
national forest, protect_class=6, ownership=national...representing the forest) 
has one or more polygons with role "outer" where all those tags apply and one 
or more polygons with role "inner" where there are inholdings and "something 
else, not national forest" are, and the tags on this multipolygon do NOT apply. 
 (These appear as "holes" in the usual way inner members do in a multipolygon).

There is nothing stopping us (and sometimes we do) from adding additional 
polygons that are "coincident with the holes" which represent "what that 
particular inholding is."  It seems to me THOSE are the places where any access 
tagging (if necessary) might apply, should your fancy run to tagging those 
specificities.

We've been tagging "large public areas with inholdings" like this (using 
multipolygons with inner members) for as long as OSM has had multipolygons.  
Why might we (re-)establish "two separate concepts" in two separate data 
structures when we already achieve this with one data structure (and possibly 
others, by that I mean "one multipolygon representing the forest, which might 
have inner members," while noting that ADDITIONAL polygons can describe what 
the inholdings ARE and superimpose on top of the holes represented by the inner 
members?  Am I missing something?

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

Re: [Talk-us] National Forest boundaries

[Mike Thompson]

On Sun, Jun 21, 2020 at 5:45 PM stevea  wrote:
>
> A large thank-you to Kevin for that deeply informative post.
>
> > brad  wrote:
> > I think its simpler and better to just create an inner boundary as was
done with the Coconino NF
>
> The Coconio NF (relation/10956348) hasn't "an" inner boundary, it has
hundreds of them.  I'm not sure I understand what Brad is saying is
"simpler and better" here, as a well-constructed multipolygon in OSM is "a
well-constructed multipolygon in OSM."  We already know how to do that so I
don't think we want to develop something else to represent the same thing.
>
> Is Brad or Mike proposing something else, like two multipolygons to
describe one national forest?
One polygon for the administrative boundary of the NF which was established
by Congress.
Zero or more polygons describing limitations on access (no need for
polygons to for access=yes, we can assume that in a NF generally), whether
they be due to private ownership, or other reasons.
The above are two separate concepts, so it is ok to have two separate OSM
elements, in my opinion.
A relation for all would be ok too, as long as the private inholdings are
not removed from the NF (which I think has been done in some cases).

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

Re: [Talk-us] National Forest boundaries

[stevea]

A large thank-you to Kevin for that deeply informative post.

> brad  wrote:
> I think its simpler and better to just create an inner boundary as was done 
> with the Coconino NF

The Coconio NF (relation/10956348) hasn't "an" inner boundary, it has hundreds 
of them.  I'm not sure I understand what Brad is saying is "simpler and better" 
here, as a well-constructed multipolygon in OSM is "a well-constructed 
multipolygon in OSM."  We already know how to do that so I don't think we want 
to develop something else to represent the same thing.

Is Brad or Mike proposing something else, like two multipolygons to describe 
one national forest?  I'd be against that (unless I hear and understand more).  
Perhaps Brad can tell the list what he thinks is "simpler and better" in the 
context of a well-defined multipolygon with one or more outer members, one or 
more inner members (as we've established) and then what he might propose?  
There is something intriguing with how Mike worded it ("separate polygons for 
inholdings, tagged with access=private and possibly ownership=private") which 
is certainly novel, and I'm willing to listen to that, but I don't quite 
understand what he means.  Two relations for one forest?  Our wider tagging 
practices don't (currently) understand this (two relations, one entity), nor do 
any renderers (that I know of), but this sort of access/ownership tagging on a 
separate polygon is an idea that might allow us to pack semantics into a 
relation (or two relations?) in a way I haven't thought of before.  Kind of 
pie-in-the-sky, but I'll listen, provided I fully understand what is being 
proposed.

We've established there are "more simply described" national forests where 
more-or-less "only" (or substantially only) the outer polygon is a member of 
the relation, and "very well described" national forests with highly complex 
memberships (perhaps multiple outer polygons, and numbering into the hundreds 
of inner elements, like Coconio).  OSM (in my opinion) has room to accept both, 
knowing that while the latter is much more complete, the former might be either 
a case of "very few if any inholdings, so essentially 'done'" or it might be "a 
rough sketch of (only) the outer polygon member to get the relation started, 
more inner polygon memberships need to be added to this relation."  And that's 
OK, but if / as we do so, let's make note of it (perhaps a FIXME tag in the 
relation with value "Incomplete; needs more inner members to describe the full 
gamut of all inholdings in this forest.")

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

Re: [Talk-us] National Forest boundaries

[Mike Thompson]

On Sat, Jun 20, 2020 at 6:31 PM Joseph Eisenberg 
wrote:
>
> > I was thinking just create separate polygons for inholdings, tagged
with access=private and possibly ownership=private
>
> While many Americans like to put "no trespassing" signs on their private
property, a privately owned parcel is not access=private unless there are
signs on the roads and paths leading into it which say so.
I don't know enough to know whether you can be prosecuted for trespassing
if it isn't posted, but if the owner shows up and asks you to leave, you
are compelled to leave.  Not too big of a deal if you are just passing
through, but if you have set up camp, it could be a hassle (particularly if
late). In any event, I don't want an encounter with a landowner due to my
trespassing, posted or not.


> Many privately-owned parcels in the national forests are used for forestry
> only, and there is no issue with crossing through on a road or trail in
> many cases.
>
Not true here in northern Colorado.  There are lots of small inholdings,
some with year round residences, some with seasonal cabins, and some that
people use for their RVs.  There is probably not an issue with passing
through on an established trail or road, but if one is travelling cross
country, aka bushwacking, it could be an issue. I also did recently
encounter private property while on an established trail  (the owner had
posted no trespassing signs). I wish I had known that ahead of time.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] Facebook achète Mapillary ! -> récupération des photos

[Christian Quest]

Le 21/06/2020 à 22:06, Romain MEHUT a écrit :
J'ai aussi, au cas où, téléchargé mes modestes 9,2 Go car je n'avais 
pas gardé de copie.


Christian, tu disais tout garder alors pourquoi les télécharger ?

Romain


Je n'ai pas tout gardé au début, et puis parfois j'ai pas fait la manip 
avant l'envoi (qui supprime localement)... donc là, j'ai tout (et je 
peux faire de la place dans mon ancien dossier).


--
Christian Quest - OpenStreetMap France


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

[Talk-cat] carreteres i pistes, unclassified vs grade1

[Jan Esquerra]

Bon dia a tothom i a totdon,

fa uns dies va sortir el tema al grup de Telegram, però no hi ha hagut més
moviment i crec que el mitjà per debatre-ho és aquí, a la llista, per no
barrejar temes i perdre el fil.
Desconec quanta gent hi ha aquí i allà, segur que falta algú.

Exposo el meu punt de vista:

A OSM hi ha una gran varietat i riquesa de tipus de vies de circulació per
vehicles (que altres mapes no tenen), així hi ha 5 categories pistes, 5
categories de carretera, a més a més de les motorway i altres (residential,
living_street, service, ...).

Crec que tots tenim clar que en les carreteres i pistes hi ha una gradació
de millor a pitjor, de com quant bona és una via de circulació, és a dir,
una *tertiary* és millor que una *unclassified*, i una *unclassified *és
millor que un *track grade1*, i un *track grade1* és millor que un *track
grade2*, i etc.

Si així és, es pot afirmar que no és el mateix una
carretereta (unclassified) que una pista asfaltada (track grade1), i per
tant, algunes diferències tindran, no? Per, mi és clar que són diferents i
així ho hem de poder diferenciar en el mapa.

Per això em sembla equivocat i desencertat dir que qualsevol via de
circulació asfaltada ja és una carretera.

Ah... El quit de la qüestió és: què vol dir millor o pitjor? I quines
són aquestes diferències i com les podem identificar objectivament?

Doncs no seré jo qui us ho resolgui, però deixeu-me que us exposi les meves
reflexions.

Des d'un punt de vista de la seva construcció, en general, i pel que jo
conec:

- en la construcció d'una pista s'adapten a lo que permet el terreny
intentant no gastar-s'hi gaires duros, o sigui que el que podem trobar és
amplada la justa, corbes molt tancades i pendent el que sigui, ...

- en canvi, en les carreteres s'hi gasten més calers buscant un traçat més
fluid i més segur, amb corbes més obertes, pendents més suaus, i si cal es
fan ponts, trinxeres, túnels. Posats a gastar, l'asfalten, la pinten i la
rematen amb cuneta, alguna senyal i guarda-rails. Quasi segur que qui està
disposat a gastar-se més calers en la construcció d'una carretera és una
administració o una gran empresa.


Des del punt de vista d'usuari de la vía:

- en una pista, encara que sàpiga que està asfaltada, circularé amb molta
atenció ja que em puc trobar sorpreses: vehicles de cara en trams estrets,
corbes sobtades i molt tancades, sense visibilitat, pendents exagerats, a
part de les condicions de conservació (ferm en mal estat, pedres, rocs,
branques, ...). És més, segons amb quin vehicle vagi (camions, remolc,
autocaravanes, etc), sense conèixer-la millor no ficar-s'hi i buscar rutes
alternatives o te la jugues a tenir problemes.
O vist d'una altra manera, anat amb un cotxe normal de nit i plovent, per
una pista asfaltada he d'anar molt alerta perque em puc trobar qualsevol
cosa.

- en una carretera puc circular més tranquil, o si més no, amb més
garanties.


Evidentment, entre aquests dos exemples teòrics hi ha mil exemples de vies
que estaran entremig. Per no parlar del traçat d'algunes carreteretes de fa
70 anys, i que malgrat la seva classificació administrativa deixen molt que
desitjar (això és tema per un altre fil, jajaja).

Proposo el següent:

1- una pista que un bon dia decideixen asfaltar-la, sense fer-hi gaires més
arranjaments és un highway = track + tracktype = grade1.
Podrem circular més ràpid i més còmodes que quan estava sense pavimentar,
però excepte la superfície, la resta segueix igual.

2- una pista, que a més a més d'asfaltar-la, li fan altres obres de
millora, com ara, eixamplar-la, arreglar corbes tancades, sanejar talussos,
amb cuneta, pintura vial, senyals verticals, guarda-rails, etc. doncs podem
dir que l'han millorat a carretera.

3- una carretera també serà aquella que ja des del seu inici, es fa un
estudi i un projecte, i s'executa amb un traçat i unes característiques
constructives que la fan millor que una simple pista afaltada.

4- en aquells casos que ni es clarament una pista que han asfaltat sense
més, ni és una carretera que sabem/veiem que s'han gastat els quartos, si
tenim dubtes fem-nos les següents preguntes:
  - té corbes molt tancades sense senyalitzar?
  - té algun tipus de pintura, senyalització o protecció que millori la
seguretat?
  - m'hi ficaria amb un vehicle de gran volum (autocaravana)?
  - de nit i plovent, conduiria tranquil?

apa, opineu si us plau

Salut

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

Re: [OSM-talk-fr] Facebook achète Mapillary !

[osm . sanspourriel]

Je ne connaissais pas mais tout ça marche aussi depuis un Droid sans
compte BigBrother.

Et mon téléphone n'est pas un des modèles en question :-( Pas loin
pourtant !

Et non je n'ai jamais créé de compte Google (ni utilisé les applis
propriétaire Google).

Enfin si l'autre jour à cause d'une vidéoconférence mais je n'ai pas
donné mon numéro de téléphone mais celui de quelqu'un d'autre^^.

/e/ utilise l'ersatz de Google Plaie Sévices ?

Merci pour ce retour d'expérience.

Jean-Yvon

Le 21/06/2020 à 16:49, Georges Dutreix via Talk-fr -
talk-fr@openstreetmap.org a écrit :



Le 21/06/2020 à 15:50, Philippe Verdy a écrit :

Tu as un compte Google sur ton Android dès le moement où tu acceptes
les conditions initiales de l'OS et que tu inscrit ton numéro de
téléphone ou email (même hors Google)


Bonjour,

Il existe des alternatives hors google, comme lineageos ou /e/, même
si elles ne sont pas encore très répandues.

J'ai un téléphone "android" fonctionnant sous /e/
(https://e.foundation/?lang=fr), et je crois que d'autres personnes
ici ont également installé cet OS.
Je peux affirmer ne jamais avoir saisi de compte google sur ce téléphone.
Je précise aussi que j'ai pû installer toutes les applis dont j'avais
besoin (banque, applis synology, sncf, etc.), et en plus elles
marchent :-)

Bien cordialement,
Georges



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



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

Re: [OSM-talk-fr] Facebook achète Mapillary ! -> récupération des photos

[Romain MEHUT]

J'ai aussi, au cas où, téléchargé mes modestes 9,2 Go car je n'avais pas 
gardé de copie.


Christian, tu disais tout garder alors pourquoi les télécharger ?

Romain

Le 21/06/2020 à 01:07, Christian Quest a écrit :

Terminé la nuit dernière pour mon compte... 640Go de photos récupérées.

Toujours dispo si vous voulez sous-traiter votre "takeout" ;)

Une remarque: inutile de demander la suppression de vos photos, 
lorsque vous avez contribué, vous avez choisit de les mettre sous une 
licence qui permet aux réutilisateurs de les conserver, même si vous 
avez changé d'avis.


Par contre, vos propres photos, vous pouvez les remettre sous la 
licence de votre choix, car vous en restez l'auteur.e



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

[OSM-talk-fr] Comment tagguer plusieurs caméras de vidéosurveillance sur un poteau

[Quentin Salles]

Bonjour,

camera:direction =valeur1;valeur2;valeur3;valeur4
devices=4


Merci Marc pour la réponse.
Il serait intéressant d'ajouter ce cas sur la page Wiki OSM :
https://wiki.openstreetmap.org/wiki/FR:Tag:man_made%3Dsurveillance
 Par contre, est-ce que quelqu'un pourra s'occuper de la page anglophone
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-us] National Forest boundaries

[Paul White]

*Sorry, forgot to send this to the mailing list...*

Thanks for the input. However, doesn't that violate "one feature, one OSM
element" ?
 I
believe we should stick with the inholding method, because separating
national forests into different relations complicates search features,
rendering, etc.

For most users, the proclamation boundary would be pretty useless if
ownership is already there. As Kevin noted, the proclamation boundary shows
an area that the government has been authorized to acquire land, and has
little impact on actual protection and land cover.

I'm glad to hear everyone's opinions and insight on this issue!

On Sun, Jun 21, 2020 at 2:15 PM Paul White  wrote:

> Thanks for the input. However, doesn't that violate "one feature, one OSM
> element" ?
>  I
> believe we should stick with the inholding method, because separating
> national forests into different relations complicates search features,
> rendering, etc.
>
> For most users, the proclamation boundary would be pretty useless if
> ownership is already there. As Kevin noted, the proclamation boundary shows
> an area that the government has been authorized to acquire land, and has
> little impact on actual protection and land cover.
>
> I'm glad to hear everyone's opinions and insight on this issue!
>
> On Sun, Jun 21, 2020 at 1:43 PM Adam Franco  wrote:
>
>> Three years ago I updated the tagging and relations
>>  of the Green Mountain
>> National Forest  in
>> Vermont after some discussion in the Tagging list (start
>> ,
>> after
>> 
>> some comments from Kevin).  What I ended up doing is setting the outer
>> "proclamation boundary" as one relation
>>  tagged with 
>> boundary=national_park +
>> boundary_type=protected_area + protect_class=6 and the actual parcels
>> are a separate relation 
>> tagged with boundary=protected_area + protect_class=6 (and
>> leisure=nature_reserve for rendering -- not sure if that is still
>> needed). Wilderness and recreation areas within the National Forest are not
>> members of the main parcel relation, but instead are their own
>> ways/relations with tagging that indicates the higher level of protection
>> in them such as protect_class=1b for wilderness areas (examples: Joseph
>> Battell Wilderness ,  Big
>> Branch Wilderness ) and
>> protect_class=5 for recreation areas (example: Moosalamoo National
>> Recreation Area ).
>>
>> I can't say that this tagging is necessarily correct, but it has proven
>> to be pretty useful in a few ways:
>>
>>1. The "proclamation boundary" is a big area that provides an
>>appropriate name on low-zoom maps.
>>2. Having the parcel relation (with cut-outs for in-holdings) is
>>super useful when exploring the forest and wanting to be aware of the
>>potential for no-trespassing signage.
>>
>> I haven't looked at other National Forests in depth, but some in CO (like 
>> Roosevelt
>> National Forest  and Pike
>> National Forest ) are
>> just one big relation with boundary=national_park +
>> boundary_type=protected_area + protect_class=6  and no separate parcel
>> relations. If the actual outer "proclamation boundary" matches the main
>> extent of the parcels that is probably much simpler. In the case of the
>> Green Mountain National Forest the "proclamation boundary" almost never
>> matches the outer edge of the parcels, but covers a much wider area --
>> hence mapping both.
>>
>> Hope this helps!
>> Adam
>>
>> On Sat, Jun 20, 2020 at 11:08 PM brad  wrote:
>>
>>>
>>> On 6/20/20 6:19 PM, Mike Thompson wrote:
>>>
>>>
>>>
>>> On Sat, Jun 20, 2020 at 5:45 PM stevea 
>>> wrote:
>>> >
>>> > I think we need both as well.  I've been doing this while watching the
>>> evolution of how we best do this as I participate in a "do our best, always
>>> better" efforts to accomplish this.  Even now!
>>> >
>>> > The idea of the first kind is simply a relation with a focus on the /
>>> a polygon with the outer (-most) membership.  The idea of the second kind
>>> is one of these plus a carefully crafted inner membership, often made up of
>>> a complex inholding distribution containing many sometimes complex
>>> themselves inner polygons.
>>> Thanks Steve for your insightful comments.
>>>
>>> I was thinking just create separate polygons for inholdings, tagged with
>>> 

Re: [OSM-talk] Facebook acquires crowdsourced mapping company Mapillary

[Marc Gemis]

> * The CIA World Factbook says there are about 64 000 000 km of roads in
>   the world.
> * Google Street View takes 100 photos per km.
> * A photosphere from my tablet, compressed using WebP at 50% quality
>   takes 2.7 MB.

I doubt the CIA number takes into account paths and tracks.
Mapillary allows you to upload images at different times (dates) and
compare them, so unlike Google you can have 2 photos taken at the same
spot. Unlike Google most Mapillary photos are not spheres.

m.

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

Re: [Talk-it] facebook compra mapillary

[Martin Koppenhoefer]

sent from a phone

> On 21. Jun 2020, at 19:39, Martin Koppenhoefer  wrote:
> 
> tra un po' FB vorrà rendere disponibili le immagini solo all'interno della 
> sua piattaforma


forse ho scritto troppo presto, ovviamente FB già da ora rende disponibile le 
foto solo all’interno della sua piattaforma, perché Mapillary è diventato parte 
della piattaforma di facebook. Così come Whatsapp, Oculus VR e altri.

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

Re: [Talk-us] National Forest boundaries

[Adam Franco]

Three years ago I updated the tagging and relations
 of the Green Mountain
National Forest  in Vermont
after some discussion in the Tagging list (start
,
after

some comments from Kevin).  What I ended up doing is setting the outer
"proclamation boundary" as one relation
 tagged with
boundary=national_park +
boundary_type=protected_area + protect_class=6 and the actual parcels are a
separate relation  tagged
with boundary=protected_area + protect_class=6 (and leisure=nature_reserve
for rendering -- not sure if that is still needed). Wilderness and
recreation areas within the National Forest are not members of the main
parcel relation, but instead are their own ways/relations with tagging that
indicates the higher level of protection in them such as protect_class=1b
for wilderness areas (examples: Joseph Battell Wilderness
,  Big Branch Wilderness
) and protect_class=5 for
recreation areas (example: Moosalamoo National Recreation Area
).

I can't say that this tagging is necessarily correct, but it has proven to
be pretty useful in a few ways:

   1. The "proclamation boundary" is a big area that provides an
   appropriate name on low-zoom maps.
   2. Having the parcel relation (with cut-outs for in-holdings) is super
   useful when exploring the forest and wanting to be aware of the potential
   for no-trespassing signage.

I haven't looked at other National Forests in depth, but some in CO
(like Roosevelt
National Forest  and Pike
National Forest ) are just
one big relation with boundary=national_park + boundary_type=protected_area
+ protect_class=6  and no separate parcel relations. If the actual outer
"proclamation boundary" matches the main extent of the parcels that is
probably much simpler. In the case of the Green Mountain National Forest
the "proclamation boundary" almost never matches the outer edge of the
parcels, but covers a much wider area -- hence mapping both.

Hope this helps!
Adam

On Sat, Jun 20, 2020 at 11:08 PM brad  wrote:

>
> On 6/20/20 6:19 PM, Mike Thompson wrote:
>
>
>
> On Sat, Jun 20, 2020 at 5:45 PM stevea  wrote:
> >
> > I think we need both as well.  I've been doing this while watching the
> evolution of how we best do this as I participate in a "do our best, always
> better" efforts to accomplish this.  Even now!
> >
> > The idea of the first kind is simply a relation with a focus on the / a
> polygon with the outer (-most) membership.  The idea of the second kind is
> one of these plus a carefully crafted inner membership, often made up of a
> complex inholding distribution containing many sometimes complex themselves
> inner polygons.
> Thanks Steve for your insightful comments.
>
> I was thinking just create separate polygons for inholdings, tagged with
> access=private and possibly ownership=private
>
> Mike
>
> I think its simpler and better to just create an inner boundary as was
> done with the Coconino NF
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-it] facebook compra mapillary

[Martin Koppenhoefer]

sent from a phone

> On 21. Jun 2020, at 18:21, Alessandro Sarretta 
>  wrote:
> 
> Questa non l'ho capita Martin. Semplicemente dai per scontato che tra un po' 
> FB vorrà rendere disponibili le immagini solo all'interno della sua 
> piattaforma, o c'è altro?


no, penso (ma non ne so niente) che continueranno a “rendere disponibili” 
(entro certi limiti, non ti faranno scaricare tutte le foto, che ne so, in 
pacchetti piccoli per zona o simile, ma potrai continuare a visualizzare ed 
usare la mappa con le foto in overlay). Quello che volevo dire è che se stai 
boicottando facebook perché non vuoi partecipare alla loro profilazione (per 
esempio da dove lo utilizzi, cosa guardi, quando lo usi, quante volte lo usi, 
con quale tipo di device e sistema operativo lo usi, ecc ecc), non potrai più 
utilizzare mapillary.


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

Re: [Talk-it] facebook compra mapillary

[Alessandro Sarretta]

On 21/06/20 09:36, Martin Koppenhoefer wrote:

On 21. Jun 2020, at 09:24, Andrea Musuruane  wrote:

Sinceramente questa isteria non la capisco. Credo che Facebook abbia tutto 
l'interesse a mantenere il servizio aperto (anzi, ora è più aperto di prima, 
dato che sono ammessi anche usi commerciali) e a continuare il rapporto con OSM.

se sei un utente Facebook non ti cambia niente, invece se non utilizzi i loro 
servizi, sì, tutto qui.


Questa non l'ho capita Martin. Semplicemente dai per scontato che tra un 
po' FB vorrà rendere disponibili le immagini solo all'interno della sua 
piattaforma, o c'è altro?


Ale


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

Re: [Talk-se] Kartlägga kollektivtrafik på vatten

[Martin Norbäck Olivers]

Det är rimligt att markera farled som way och använda relationer som
färjelinjer.

Dock kan man fundera lite, jag har sett på moderna sjökort att de markerar
farled som ett område (vilket det ju egentligen är) istället för en linje.
Farleden är ju hela området mellan begränsningsmärkena, och den kan vara
hundra meter bred.

sön 21 juni 2020 kl. 17:50 skrev Essin :

> Hej!
>
> Tycker att alla dina synpunkter låter vettiga. Jag håller med om att olika
> färjelinjer som separata ways är alldeles för gyttrigt. Med förbehåll för
> att jag är landkrabba tycker jag egentligen att alla relationer som följer
> samma farled borde samlas på samma way, analogt med hur det fungerar på
> land där långfärdsbussar och stadsbussar kan följa samma gator, men det
> skulle kräva samråd med mappare i andra länder och förmodligen också
> datakonsumenter, så det kanske är ett rimligt första steg att samla en
> operator/network. Om du inte redan har sett det finns det ett försök till
> sammanställning av de linjer som redan är inlagda/påbörjade [1].
>
> [1]
> https://wiki.openstreetmap.org/wiki/Sweden/Public_transport#Waxholmsbolaget
>
> //Essin
>
> Den sön 21 juni 2020 kl 13:52 skrev Erik Åman :
>
>> Hej!
>>
>> Jag funderar på att försöka förbättra hur båtlinjer i Stockholms skärgård
>> är kartlagda. Det vore intressant att få flera personers syn på hur det
>> görs bäst innan jag sätter igång. Det finns nog få områden i världen som
>> har ett lika komplicerat kollektivtrafiksystem på vatten, så jag tror att
>> detta är relevant att diskutera på den svenska listan.
>>
>> Det vanliga i OSM är att färjelinjer modelleras med alla attribut på en
>> way. I detta fall tror jag dock att man bör använda relationer (enligt
>> Public Transport Version 2), även om wiki-sidan [1] varnar att stödet för
>> det är begränsat. Försöker man rita ut varje färjelinje separat, blir det
>> på tok för gyttrigt (vilket är tydligt exempelvis runt Vaxholm).
>>
>> Vad jag undrar är till att börja med vilka relationer som bör utnyttja
>> samma way. Långdistanstrafiken med stora fartyg över Östersjön är redan
>> till största delen i from av relationer, se exempelvis way 140517501 [2]
>> och relationerna som använder sig av den. Min intuition säger mig att även
>> om de mindre skärgårdsbåtarna till viss del går i samma farled, bör nog
>> inte deras relationer använda sig av samma way (som ju räknas som en del av
>> Europaväg 20). Men var drar man gränsen?
>> - När det är olika värden för vilka som får åka med båten, exempelvis
>> motor_vehicle=yes/no
>> - När "operator" eller "network" har olika värden?
>> En relaterad fråga är vilka attribut som man bör lämna på en way för att
>> möjliggöra för datakonsumenter som inte har stöd för relationer.
>>
>> En annan fundering jag har är var man kan och bör ha förgreningspunkter.
>> Bara vid bryggor eller även ute i vattnet (som redan nu är fallet med
>> långdistanstrafiken). Mellan Kymmendö och Dalarö [3] finns exempelvis två
>> punkter där man kanske eller kanske inte vill ha förgreningar ute på
>> vattnet. Söder om Kymmendö (öster om Ornö) finns en färjelinje som
>> trafikerar många bryggor, medan den andra bara stannar vid vissa av
>> bryggorna, vilket också kan föranleda förgreningspunkter ute på vattnet.
>>
>> Det finns också fall där olika färjelinjer utan uppenbar anledning
>> kartlagts på olika sidor av mindre öar som inte trafikeras, exempelvis
>> nordväst om Sandhamn [4]. Förmodligen beror det på väder,
>> trafikförhållanden eller annat just den dag då någon lade till just den
>> linjen i OSM. Ska man slå ihop sådana fall till en gemensam sträcka som går
>> antingen den vanligaste eller den kortaste vägen? Kanske jämförbart med att
>> vid dubbelspårig järnväg lägger man relationen för en riktning på det spår
>> som oftast används, även om det inte finns någon garanti för att tåget
>> alltid går på det spåret.
>>
>>
>> [1] https://wiki.openstreetmap.org/wiki/Tag:route%3Dferry
>> [2] https://www.openstreetmap.org/way/140517501
>> [3] https://www.openstreetmap.org/#map=14/59.1227/18.4663
>> [4] https://www.openstreetmap.org/#map=14/59.2951/18.9097
>>
>>
>> /Erik Åman
>> ___
>> Talk-se mailing list
>> Talk-se@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-se
>>
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se
>
-- 
Martin Norbäck Olivers
IT-konsult, Masara AB
Telefon: +46 703 22 70 12
E-post: mar...@norpan.org
Kärrhöksvägen 4
656 72 Skattkärr
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [Talk-se] Kartlägga kollektivtrafik på vatten

[Essin]

Hej!

Tycker att alla dina synpunkter låter vettiga. Jag håller med om att olika
färjelinjer som separata ways är alldeles för gyttrigt. Med förbehåll för
att jag är landkrabba tycker jag egentligen att alla relationer som följer
samma farled borde samlas på samma way, analogt med hur det fungerar på
land där långfärdsbussar och stadsbussar kan följa samma gator, men det
skulle kräva samråd med mappare i andra länder och förmodligen också
datakonsumenter, så det kanske är ett rimligt första steg att samla en
operator/network. Om du inte redan har sett det finns det ett försök till
sammanställning av de linjer som redan är inlagda/påbörjade [1].

[1]
https://wiki.openstreetmap.org/wiki/Sweden/Public_transport#Waxholmsbolaget

//Essin

Den sön 21 juni 2020 kl 13:52 skrev Erik Åman :

> Hej!
>
> Jag funderar på att försöka förbättra hur båtlinjer i Stockholms skärgård
> är kartlagda. Det vore intressant att få flera personers syn på hur det
> görs bäst innan jag sätter igång. Det finns nog få områden i världen som
> har ett lika komplicerat kollektivtrafiksystem på vatten, så jag tror att
> detta är relevant att diskutera på den svenska listan.
>
> Det vanliga i OSM är att färjelinjer modelleras med alla attribut på en
> way. I detta fall tror jag dock att man bör använda relationer (enligt
> Public Transport Version 2), även om wiki-sidan [1] varnar att stödet för
> det är begränsat. Försöker man rita ut varje färjelinje separat, blir det
> på tok för gyttrigt (vilket är tydligt exempelvis runt Vaxholm).
>
> Vad jag undrar är till att börja med vilka relationer som bör utnyttja
> samma way. Långdistanstrafiken med stora fartyg över Östersjön är redan
> till största delen i from av relationer, se exempelvis way 140517501 [2]
> och relationerna som använder sig av den. Min intuition säger mig att även
> om de mindre skärgårdsbåtarna till viss del går i samma farled, bör nog
> inte deras relationer använda sig av samma way (som ju räknas som en del av
> Europaväg 20). Men var drar man gränsen?
> - När det är olika värden för vilka som får åka med båten, exempelvis
> motor_vehicle=yes/no
> - När "operator" eller "network" har olika värden?
> En relaterad fråga är vilka attribut som man bör lämna på en way för att
> möjliggöra för datakonsumenter som inte har stöd för relationer.
>
> En annan fundering jag har är var man kan och bör ha förgreningspunkter.
> Bara vid bryggor eller även ute i vattnet (som redan nu är fallet med
> långdistanstrafiken). Mellan Kymmendö och Dalarö [3] finns exempelvis två
> punkter där man kanske eller kanske inte vill ha förgreningar ute på
> vattnet. Söder om Kymmendö (öster om Ornö) finns en färjelinje som
> trafikerar många bryggor, medan den andra bara stannar vid vissa av
> bryggorna, vilket också kan föranleda förgreningspunkter ute på vattnet.
>
> Det finns också fall där olika färjelinjer utan uppenbar anledning
> kartlagts på olika sidor av mindre öar som inte trafikeras, exempelvis
> nordväst om Sandhamn [4]. Förmodligen beror det på väder,
> trafikförhållanden eller annat just den dag då någon lade till just den
> linjen i OSM. Ska man slå ihop sådana fall till en gemensam sträcka som går
> antingen den vanligaste eller den kortaste vägen? Kanske jämförbart med att
> vid dubbelspårig järnväg lägger man relationen för en riktning på det spår
> som oftast används, även om det inte finns någon garanti för att tåget
> alltid går på det spåret.
>
>
> [1] https://wiki.openstreetmap.org/wiki/Tag:route%3Dferry
> [2] https://www.openstreetmap.org/way/140517501
> [3] https://www.openstreetmap.org/#map=14/59.1227/18.4663
> [4] https://www.openstreetmap.org/#map=14/59.2951/18.9097
>
>
> /Erik Åman
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se
>
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [Talk-us] Labeling county roads (Idaho)

[Kevin Kenny]

On Sun, Jun 21, 2020 at 9:31 AM  wrote:
> Started mapping an area of the Idaho panhandle around the Kootenai
> river. I notice that currently minor roads have a "County Road nn" name
> but TIGER2019 data also has names such as "Acacia Avenue". I think most
> map users would want to use the "Acacia Avenue" name as it what would be
> listed in postal addresses and they'd want to search it in applications
> such as OSMand. Question is how to handle this. Also, what to set the
> "ref" to for county roads.

Not an Idahoan, so take this with a grain of salt.  Does Idaho
actually have numbered county highways other than the grid streets?
(Many Western states do not.)

Most states' practice will set the 'ref' to something like 'CR 23',

It's unnecessary to have a name like 'County Road 23'. In fact, if you
do have such a name, a lot of routing software will announce, 'turn
right on CR 23, County Road 23'. If the road has no other name, add
the tag `noname=yes` to silence warnings about a tertiary highway
without a name.

Please, create a route relation for each road with a reference.
Include in the relation all the road segments that make up the route.
Minimal attributes for the relation would be `type=route route=road
network=US:ID:Boundary ref=29A` for Boundary County Road 29A. The
corresponding street segment would have `highway=tertiary
name="Chokecherry Drive" ref="CR 29A"`, and it would ideally have
attributes like surface, maxspeed, lanes,  Having the relation
provides the data model with a way to group all the way segments;
roads get split all the time when people decide to map small bridges,
or when speed limits or lane counts changed, and so on.



-- 
73 de ke9tv/2, Kevin

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

Re: [Talk-us] Labeling county roads (Idaho)

[Clifford Snow]

Be cautious using TIGER data in rural areas. I suspect many of the small
counties don't have the resources to send updates to Census. I'd recommend
looking at county and state data sources for accurate road names.

Best,
Clifford

On Sun, Jun 21, 2020 at 6:29 AM  wrote:

>
> Newby here.
>
> Started mapping an area of the Idaho panhandle around the Kootenai
> river. I notice that currently minor roads have a "County Road nn" name
> but TIGER2019 data also has names such as "Acacia Avenue". I think most
> map users would want to use the "Acacia Avenue" name as it what would be
> listed in postal addresses and they'd want to search it in applications
> such as OSMand. Question is how to handle this. Also, what to set the
> "ref" to for county roads.
>
> There's not much information on the roads tagging page:
>
>
> https://wiki.openstreetmap.org/wiki/United_States_roads_tagging#Individual_states_2
>
> Proposal: use alt_name for "County Road nn" and name for "Acacia Avenue"
> where a name is given. (I've seen name_1 used but this is not really a
> "standard" OSM tag, AFAIK.)
>
> For ref: set the ref to the county road number until someone can come up
> with a better proposal...
>
> Any Idahoans have any information?
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>


-- 
@osm_washington
www.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-se] Administrativa gränser

[Essin]

Hej!

Tycker att det verkar rimligt att göra något i den här riktningen. Jag
började titta på det här problemet för flera år sedan men kom aldrig
riktigt nånvart. Jag upptäckte då att i Sundsvalls kommun är
nyckelkodsområden inlagda på nivå 9 (öppna data enligt
http://sundsvall.se/kommun-och-politik/fakta-om-sundsvalls-kommun/psi-data-oppna-data/
), men det är kanske ett fall för boundary=census?

Ett mindre problem är att vissa kommundelar med administrativ funktion (som
Stockholms stadsdelsområden) är större än distrikt, andra mindre. Jag
tycker att det är rimligt att betrakta båda som aktuella administrativa
enheter, så vi får helt enkelt leva med att vissa nivå 9-enheter omfattar
flera nivå 8-enheter.

När det gäller stadsdelar har vissa kommuner flera nivåer, t ex Lund där
Lunds stad (den del av kommunen som är indelad i stadsdelar) för närvarande
är nivå 8, "stadsdelsområden" (fem grupper av stadsdelar) är nivå 9 och de
egentliga stadsdelarna är nivå 10. Går det att passa in i det här systemet?

För att skilja på olika typer av historiska enheter vore det bra att även
med boundary=historic använda admin_level (eller en motsvarande tagg med
annat namn). På så sätt skulle man kunna ha en hierarki för
landsdelar-landskap-(härader?)-socknar-fjärdingar/rotar/andra mindre
enheter. När man pratar om "socknar" när det gäller t ex fornminnen har jag
fått intrycket att det är jordregistersocknar som avses.
Jordregistersocknarna, som blev historiska i och med fastighetsdatareformen
1976-1995 (olika tidpunkter i olika län), sammanföll inte alltid helt med
kyrksocknarna/församlingarna, men skillnaderna är ofta så små att med de
källor som vi har tillgång till idag är det nog inte meningsfullt att ha
separata OSM-objekt för jordregistersocknar och distrikt utom där det
skedde församlingssammanslagningar före 2000 som inte påverkade
jordregistersocknarna. Jag har sett några sådana fall mappade i
Västergötland.

Hälsningar,
Essin



Den ons 10 juni 2020 kl 12:53 skrev Andreas Vilén :

> Hej!
>
> Bra genomgång!
>
> Håller med om det mesta av vad du skriver. Angående de roten du hittat i
> Lund syftar de på det som beskrivs här:
> https://sv.wikipedia.org/wiki/Rote#Stadsdel_och_folkbokf%C3%B6ringsdistrikt.
> De är historiska och kan nog ändras till en sådan taggning. De används dock
> då och då i dagligt tal. Indelningen används även i
> https://sv.wikipedia.org/wiki/Lunds_stadsk%C3%A4rna. Man kan dock notera
> att källorna är från 60- och 80-tal.
>
> MVH Andreas
>
> On Wed, Jun 10, 2020 at 10:29 AM  wrote:
>
>> Hej!
>>
>> Jag har tagit en titt på de administrativa gränser
>> (boundary=administrative) som förekommer på OSM i Sverige. Dels vill
>> jag ifrågasätta användningen av landsdelar som administrativ
>> indelning, dels vill jag ha en mer konsekvent användning av
>> admin_level för nivå 8, 9 och 10, det vill säga indelningar mindre än
>> kommuner.
>>
>> I första frågan så finns det relationer för Norrland, Svealand och
>> Götaland definierade på nivå 3, mellan Sverige som land (nivå 2) och
>> län (nivå 4). Vad jag vet så är indelningen i landsdelar högst
>> inofficiell om än allmänt accepterad, men absolut inte något som
>> förekommer som administrativ indelning. Jag föreslår att admin_level=3
>> tas bort och att relationerna ändras till boundary=historic på samma
>> sätt som landskapen.
>>
>> I andra frågan har jag med Overpass hämtat hem stora delar av Sverige
>> och undersökt vilka indelningar som finns på nivåerna 8, 9 och 10. På
>> OSM-wikin finns en sida
>> (
>> https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#10_admin_level_values_for_specific_countries)
>> som dokumenterar vad som till stor del är sant, men en hel del avvikelser
>> förekommer.
>>
>> Enligt den ska följande gälla:
>> Nivå 2 är Sverige som land.
>> Nivå 3 är landsdelar.
>> Nivå 4 är län.
>> Nivå 5-6 används ej.
>> Nivå 7 är kommuner.
>> Nivå 8 används ej.
>> Nivå 9 är stadsdelsområden/stadsdelsnämndsområden/stadsdel (Umeå).
>> Nivå 10 är stadsdelar/primärområden/stadsdelsområden (Umeå).
>>
>> I praktiken förekommer följande:
>> Nivå 2-7 stämmer.
>>
>> Nivå 8 används för tätortsgränser i ett antal städer (Gävle, Göteborg,
>> Lund, Skellefteå, Umeå, Åhus). En del också tillsammans med place=city
>> eller place=town. De flesta har en kommentar i stil med
>> "note=Tätortsgränsen följer inte LMs polygon slaviskt eftersom att
>> denna inte täckte alla områden ordentligt" eller
>> "description=Approximation of Lund city limit, fixme=refine". I
>> Sundsvall/Västernorrland används istället nivå 8 till
>> distriktsindelning och även till församlingar. I Stockholmsområdet
>> finns en relation "Huvudsta" med nivå 8.
>>
>> Nivå 9 används till stor del för områden i städer som är större än
>> stadsdelar, oavsett vad benämningen är på sådana områden i olika
>> städer. I Ljungby används nivå 9 för stadsdelar tillsammans med
>> place=suburb eller place=neighbourhood. I Sundsvall/Västernorrland
>> förekommer istället statistikområden 

Re: [Talk-se] Namnsättning av "dubbel-ö" i Vänern

[Essin]

Det här är ett intressant ämne, och jag tror att det finns flera möjliga
lösningar. Jag har mappat enligt alternativ 3 ibland, även om jag inte
heller är helt övertygad om att det är riktigt renlärigt. Om den ena ön är
tydligt större än den andra kanske man kan utgå från att det är den som har
gett namn åt den sammanvuxna ön, och betrakta den andra ön som en halvö. I
alternativ 1 skulle jag inte sätta place=islet på den sammanvuxna ön,
eftersom det ändå framgår av en inner-ring i en multipolygon (eller en ring
av ways med natural=coastline). Som det står på
https://wiki.openstreetmap.org/wiki/Key:place är place-taggarna för
namngivna platser, alltså betyder place=islet "det här är en namngiven
plats, mer specifikt en namngiven holme/liten ö".

//Essin

Den tis 2 juni 2020 kl 11:17 skrev Lennart Romberg <
lennart.romb...@gmail.com>:

> OK, ändrade enligt förslaget. JOSM-validatorn hade i alla fall inga
> invändningar. Får se om osmose klagar, men det brukar ta nån dag innan man
> ser.
> / Lennart
>
> Den tis 2 juni 2020 kl 10:39 skrev Lennart Romberg <
> lennart.romb...@gmail.com>:
>
>> Mm, funderade även på detta men på wikin står  "An *island* is any piece
>> of land that is completely surrounded by water" och jag antog att samma
>> gäller "islet". Men visst, om man inte måste hålla strikt på "completely
>> surrounded" så köper jag gärna detta. Invändningar, någon?
>> / Lennart
>>
>> Den tis 2 juni 2020 kl 10:03 skrev Tomas Marklund <
>> tomasmarklun...@gmail.com>:
>>
>>> Jag tycker det ser ut som två öar som har växt ihop mer och mer
>>> såtillvida att det idag bara finns blötmark som sammanbinder dem. På
>>> flygfotona ser det inte ut att finnas nåt egentligt "vatten" mellan dem.
>>> Egentligen bara en ö, men de båda tidigare öarnas namn lever kvar på
>>> respektive "del" av ön.
>>>
>>> Så, här kommer alternativ 3 :-)
>>>
>>> Jag skulle göra två multipolygoner av dem, där var och en av MParna är
>>> en place=islet, och att de har en gemensam sträcka i mitten (svart) där de
>>> möts. MP1 (röd och svart sträcka) är place=islet, name=Näbben och MP2 (blå
>>> och svart sträcka). är place=islet , name=Näthall.
>>>
>>> I den stora multipolygonen "vänern" ingår då röd och blå sträcka som
>>> "inner".
>>>
>>> [image: image.png]
>>>
>>> /Tomas
>>>
>>> Den tis 2 juni 2020 kl 09:46 skrev Lennart Romberg <
>>> lennart.romb...@gmail.com>:
>>>
 Hej!

 Noterade att en av Sättersholmarna utanför Hammarö i Vänern saknade
 namn i OSM.
 https://www.openstreetmap.org/edit?editor=id#map=16/59.3049/13.6137

 Kollar man på LM så har nord- och syddelen olika namn ("Näbben" resp
 "Näthall"). Verkar inte finnas något namn på "hela ön". Tittar man noga så
 verkar det finnas något smalt vattendrag (utan flödesriktning) mellan
 halvorna. Har inte kollat på plats hur det ser ut. Nu funderar jag på olika
 metoder att få in dessa namn på något vettigt sätt.

 En fråga är om det är en eller två öar. Finns antagligen nån ö-databas
 som ger det officiella svaret men har inte lyckats snoka upp den.

 1) En ö. Behålla place=islet och inte ge denna ett namn. Sätta
 punktnod natural=peninsula + name=xx på respektive halva. Missbruk av
 peninsula?

 2) Dela ön i två. Rita om till två separata place=islet och sätta namn
 på dem. Det smala utrymmet mellan dem ("vattendraget") får höra till Vänern
 (som ett supersmalt sund). Fast är det verkligen två öar?

 Duger något av dessa, eller finns bättre förslag?

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

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

Re: [OSM-talk-fr] Facebook achète Mapillary !

[Georges Dutreix via Talk-fr]

Le 21/06/2020 à 15:50, Philippe Verdy a écrit :
Tu as un compte Google sur ton Android dès le moement où tu acceptes 
les conditions initiales de l'OS et que tu inscrit ton numéro de 
téléphone ou email (même hors Google)


Bonjour,

Il existe des alternatives hors google, comme lineageos ou /e/, même si 
elles ne sont pas encore très répandues.


J'ai un téléphone "android" fonctionnant sous /e/ 
(https://e.foundation/?lang=fr), et je crois que d'autres personnes ici 
ont également installé cet OS.

Je peux affirmer ne jamais avoir saisi de compte google sur ce téléphone.
Je précise aussi que j'ai pû installer toutes les applis dont j'avais 
besoin (banque, applis synology, sncf, etc.), et en plus elles marchent :-)


Bien cordialement,
Georges



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

Re: [OSM-talk-fr] Data OSM

[Philippe Verdy]

J'aime bien aussi le nom "catalogue", pour son ouverture à des
données diverses et de sources diverses. Et mieux que "data" qui fait trop
propriétaire. "Catalogue" reste lisible aussi par les anglophones
(britanniques au moins, les US abrégeant toutes les finales muettes pour
simplifier l'orthographe au mépris parfois de la sémantique).

Le dim. 21 juin 2020 à 15:47, LeTopographeFou  a
écrit :

> Génial comme site !
>
> Comme nous n'avons pas à rougir de notre belle langue je suis pour un nom
> francophone et n'est pas pour autant imprononçable pour un anglophone.
> 'themes' me parait remplir les deux critères en matière de sous-domaine et
> en plus cela illustre bien l'usage. Osmose est génial pour cela.
>
> Par contre pour ce qui est du nom/logo du site l'appeler juste 'Thèmes' me
> fait tout bizarre. Mais c'est peut-être une question d'habitude.
>
> LeTopographeFou
>
> Le 20/06/2020 à 23:02, Georges Dutreix via Talk-fr a écrit :
>
> +1
>
> 20 juin 2020 21:20:39 osm.sanspourr...@spamgourmet.com:
>
> J'aime la dernière proposition sur Loomio : themes.openstreetmap.fr
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Facebook achète Mapillary !

[Philippe Verdy]

Tu as un compte Google sur ton Android dès le moement où tu acceptes les
conditions initiales de l'OS et que tu inscrit ton numéro de téléphone ou
email (même hors Google), qui deviennent tes identifiants chez Google. Ce
la se passe par défaut. Et un Android sans Google Play n'est pas plus sûr:
c'est que Google Play a été remplacé par un équivalent du constructeur qui
lui aussi va te forcer à accepter ses conditions de collecte de données
pour utiliser leur propre "app store". Samsung, LG, Sony et autres te
créent un compte avec ton mail et ton téléphone dès le paramétrage initial.
Si tu refuses cette inscription (et la collecte automatique de données qui
va avec), il n'y a presque plus rien qui fonctionne sur le smartphone: tu
peux téléphoner, peut-être utiliser un navigateur internet, mais pour les
apps tu dois te débrouiller et trouver des apps Android qui fonctionnent
sans les Gooply Play Service (il y en a très peu, la plupart les utilisant
aussi pour l'envoi de publicités, notamment toutes les applis gratuites).
Ce qui n'est pas clair si tu utilises autre chose que Google, c'est que les
autres ne te donnes aucun accès aux données collctées et aucun contrôle,
alors que Google (ou Microsoft) te permet de voir tout et même tout effacer
ou effacer sélectivement. JE ne pense pas que les utilisateurs d'iPhone ont
davantage de choix: la création d'un compte chez Apple est là aussi
implicite dès l'acceptation des conditions initiales (et si tu les refuse,
ton iPhone ne sert plus à rien, car il n'y a aucune appli ailleurs que sur
l'AppStore d'Apple, qui impose ses APIs et cette collecte). On te pose la
question une seule fois, dès le paramétrage de l'appareil, et ensuite plus
rien ne l'indique.
La seule alternative serait un OS libre, mais les constructeur font tout ce
qu'ils peuvent pour empêcher leur installation (rootage obligatoire mais
non documenté, non supporté, clauses abusives et illégales de fin de
garantie...). et même si on croit que les constructeur laisse un OS libre
s'exécuter, il y a encore un "hyperviseur" masqué en arrière plan, ton OS
est virtualisé par une combinaison de matériel et logiciel (firmware), et
c'est le cas aussi aujourd'hui de TOUT les PC et de nombreux matériels
intégrés qui ont leur propre firmware caché et très fortement sécurisé.
Même un simple clavier a un firmware bien protégé, de même que les
interfaces réseau Etthernet, Wifi, mobile, et tout un tas de contrôleurs
pour le son, l'affichage. Les cartes mères protègent leurs BIOS, et l'UEFI
n'autorise pas de tout changer. Même le CPU a son firmware (appelé
microcode).
Les interfaces propriétaires sont partout!



Le ven. 19 juin 2020 à 10:19, Cyrille37 OSM  a
écrit :

> Le 19/06/2020 à 08:31, Cédric Frayssinet a écrit :
> > Suis content d'avoir toujours contribué sur OpenStreetCam (Mapillary
> > ne fonctionnant pas sans les Google Play Services sur mon smartphone).
>
> Ah bon ? Sur mon android je n'ai pas de compte Google et Mapillary
> fonctione très bien ; c'est Geovelo par contre qui n'enregistre pas mes
> parcours sans compte Google.
>
> Cyrille37
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Data OSM

[LeTopographeFou]

Génial comme site !

Comme nous n'avons pas à rougir de notre belle langue je suis pour un 
nom francophone et n'est pas pour autant imprononçable pour un 
anglophone. 'themes' me parait remplir les deux critères en matière de 
sous-domaine et en plus cela illustre bien l'usage. Osmose est génial 
pour cela.


Par contre pour ce qui est du nom/logo du site l'appeler juste 'Thèmes' 
me fait tout bizarre. Mais c'est peut-être une question d'habitude.


LeTopographeFou

Le 20/06/2020 à 23:02, Georges Dutreix via Talk-fr a écrit :

+1

20 juin 2020 21:20:39 osm.sanspourr...@spamgourmet.com:

J'aime la dernière proposition sur Loomio : themes.openstreetmap.fr


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

[Talk-us] Labeling county roads (Idaho)

[tj-osmwiki]

Newby here.

Started mapping an area of the Idaho panhandle around the Kootenai
river. I notice that currently minor roads have a "County Road nn" name
but TIGER2019 data also has names such as "Acacia Avenue". I think most
map users would want to use the "Acacia Avenue" name as it what would be
listed in postal addresses and they'd want to search it in applications
such as OSMand. Question is how to handle this. Also, what to set the
"ref" to for county roads.

There's not much information on the roads tagging page:

https://wiki.openstreetmap.org/wiki/United_States_roads_tagging#Individual_states_2

Proposal: use alt_name for "County Road nn" and name for "Acacia Avenue"
where a name is given. (I've seen name_1 used but this is not really a
"standard" OSM tag, AFAIK.)

For ref: set the ref to the county road number until someone can come up
with a better proposal...

Any Idahoans have any information?

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

Re: [Talk-GB] TfL Cycle Infrastructure Database - matching against OSM

[David Woolley]

On 21/06/2020 13:38, Mateusz Konieczny via Talk-GB wrote:

Is it ok for pedestrians to walk on
the carriageway and cross the road
together with cyclists in place
marked by bicycle paintings?


It's legal for them to do so, which is what determines access.  They 
don't get any priority.




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

[Talk-es] semanarioOSM Nº 517 2020-06-09-2020-06-15

[theweekly . osm]

Hola, el semanario Nº 517, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en *español*:

https://www.weeklyosm.eu/es/archives/13289/

¡Disfruta!

¿Sabías que también puedes enviar mensajes para la nota semanal sin ser 
miembro? Simplemente ingresa a https://osmbc.openstreetmap.de/login con tu 
cuenta de OSM. Lee más sobre cómo escribir una publicación aquí: 
http://www.weeklyosm.eu/es/this-news-should-be-in-weeklyosm 

semanarioOSM? 
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

[OSM-co] semanarioOSM Nº 517 2020-06-09-2020-06-15

[theweekly . osm]

Hola, el semanario Nº 517, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en *español*:

https://www.weeklyosm.eu/es/archives/13289/

¡Disfruta!

¿Sabías que también puedes enviar mensajes para la nota semanal sin ser 
miembro? Simplemente ingresa a https://osmbc.openstreetmap.de/login con tu 
cuenta de OSM. Lee más sobre cómo escribir una publicación aquí: 
http://www.weeklyosm.eu/es/this-news-should-be-in-weeklyosm 

semanarioOSM? 
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-co mailing list
Talk-co@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-co

[Talk-cl] semanarioOSM Nº 517 2020-06-09-2020-06-15

[theweekly . osm]

Hola, el semanario Nº 517, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en *español*:

https://www.weeklyosm.eu/es/archives/13289/

¡Disfruta!

¿Sabías que también puedes enviar mensajes para la nota semanal sin ser 
miembro? Simplemente ingresa a https://osmbc.openstreetmap.de/login con tu 
cuenta de OSM. Lee más sobre cómo escribir una publicación aquí: 
http://www.weeklyosm.eu/es/this-news-should-be-in-weeklyosm 

semanarioOSM? 
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-cl mailing list
Talk-cl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cl

[talk-latam] semanarioOSM Nº 517 2020-06-09-2020-06-15

[theweekly . osm]

Hola, el semanario Nº 517, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en *español*:

https://www.weeklyosm.eu/es/archives/13289/

¡Disfruta!

¿Sabías que también puedes enviar mensajes para la nota semanal sin ser 
miembro? Simplemente ingresa a https://osmbc.openstreetmap.de/login con tu 
cuenta de OSM. Lee más sobre cómo escribir una publicación aquí: 
http://www.weeklyosm.eu/es/this-news-should-be-in-weeklyosm 

semanarioOSM? 
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
talk-latam mailing list
talk-latam@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-latam

[Talk-cu] semanarioOSM Nº 517 2020-06-09-2020-06-15

[theweekly . osm]

Hola, el semanario Nº 517, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en *español*:

https://www.weeklyosm.eu/es/archives/13289/

¡Disfruta!

¿Sabías que también puedes enviar mensajes para la nota semanal sin ser 
miembro? Simplemente ingresa a https://osmbc.openstreetmap.de/login con tu 
cuenta de OSM. Lee más sobre cómo escribir una publicación aquí: 
http://www.weeklyosm.eu/es/this-news-should-be-in-weeklyosm 

semanarioOSM? 
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-cu mailing list
Talk-cu@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cu

[Talk-bo] semanarioOSM Nº 517 2020-06-09-2020-06-15

[theweekly . osm]

Hola, el semanario Nº 517, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en *español*:

https://www.weeklyosm.eu/es/archives/13289/

¡Disfruta!

¿Sabías que también puedes enviar mensajes para la nota semanal sin ser 
miembro? Simplemente ingresa a https://osmbc.openstreetmap.de/login con tu 
cuenta de OSM. Lee más sobre cómo escribir una publicación aquí: 
http://www.weeklyosm.eu/es/this-news-should-be-in-weeklyosm 

semanarioOSM? 
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-bo mailing list
Talk-bo@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-bo

[Talk-it] weeklyOSM #517 2020-06-09-2020-06-15

[weeklyteam]

Il settimanale di notizie su OSM, numero # 517, è ora disponibile online in 
italiano, 
fornendo come sempre un riassunto di molte cose che accadono nel mondo 
OpenStreetMap: 

https://www.weeklyosm.eu/it/archives/13289/

Buona lettura! 

Sai che possono anche inviare messaggi per il weeklyOSM? Basta effettuare il 
login 
su https://osmbc.openstreetmap.de/login con il tuo account OSM. 

Per saperne di più su come scrivere un messaggio, leggi qui: 
http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm 
weeklyOSM? 

chi: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
dove?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-ca] hebdoOSM Nº 517 2020-06-09-2020-06-15

[theweekly . osm]

Bonjour,

Le résumé hebdomadaire n° 517 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

https://www.weeklyosm.eu/fr/archives/13289/

Bonne lecture !

Saviez-vous que vous pouvez vous aussi soumettre des messages pour la note 
hebdomadaire sans être membre ? Il vous suffit de vous connecter sur 
https://osmbc.openstreetmap.de/login avec votre compte OSM. Pour en savoir plus 
sur la rédaction d'un article, cliquez ici: 
http://www.weeklyosm.eu/fr/this-news-should-be-in-weeklyosm

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[OSM-talk-fr] hebdoOSM Nº 517 2020-06-09-2020-06-15

[theweekly . osm]

Bonjour,

Le résumé hebdomadaire n° 517 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

https://www.weeklyosm.eu/fr/archives/13289/

Bonne lecture !

Saviez-vous que vous pouvez vous aussi soumettre des messages pour la note 
hebdomadaire sans être membre ? Il vous suffit de vous connecter sur 
https://osmbc.openstreetmap.de/login avec votre compte OSM. Pour en savoir plus 
sur la rédaction d'un article, cliquez ici: 
http://www.weeklyosm.eu/fr/this-news-should-be-in-weeklyosm

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-ht] hebdoOSM Nº 517 2020-06-09-2020-06-15

[theweekly . osm]

Bonjour,

Le résumé hebdomadaire n° 517 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

https://www.weeklyosm.eu/fr/archives/13289/

Bonne lecture !

Saviez-vous que vous pouvez vous aussi soumettre des messages pour la note 
hebdomadaire sans être membre ? Il vous suffit de vous connecter sur 
https://osmbc.openstreetmap.de/login avec votre compte OSM. Pour en savoir plus 
sur la rédaction d'un article, cliquez ici: 
http://www.weeklyosm.eu/fr/this-news-should-be-in-weeklyosm

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ht mailing list
Talk-ht@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ht
Notez! Vous pouvez utiliser Google Translate (http://translate.google.com) pour 
traduire les messages.

[Talk-africa] hebdoOSM Nº 517 2020-06-09-2020-06-15

[theweekly . osm]

Bonjour,

Le résumé hebdomadaire n° 517 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

https://www.weeklyosm.eu/fr/archives/13289/

Bonne lecture !

Saviez-vous que vous pouvez vous aussi soumettre des messages pour la note 
hebdomadaire sans être membre ? Il vous suffit de vous connecter sur 
https://osmbc.openstreetmap.de/login avec votre compte OSM. Pour en savoir plus 
sur la rédaction d'un article, cliquez ici: 
http://www.weeklyosm.eu/fr/this-news-should-be-in-weeklyosm

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-africa mailing list
Talk-africa@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-africa

[OSM-talk] weeklyOSM #517 2020-06-09-2020-06-15

[weeklyteam]

The weekly round-up of OSM news, issue # 517,
is now available online in English, giving as always a summary of a lot of 
things happening in the openstreetmap world:

 https://www.weeklyosm.eu/en/archives/13289/

Enjoy! 

Did you know that you can also submit messages for the weeklyOSM? Just log in 
to https://osmbc.openstreetmap.de/login with your OSM account. Read more about 
how to write a post here: 
http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm 

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-de] weeklyOSM #517 2020-06-09-2020-06-15~+~-

[weeklyteam]

Die Wochennotiz Ausgabe Nr. # 517, ist nun verfügbar - 
wie immer mit vielen Nachrichten aus dem OSM-Universium:

https://www.weeklyosm.eu/de/archives/13289/

Viel Spaß beim Lesen.  

Euer Wochennotizteam

Wusstet ihr, dass ihr auch selbst Meldungen für die Wochennotiz
einreichen könnt? Einfach auf https://osmbc.openstreetmap.de/ 
mit eurem OSM-Benutzerkonto anmelden und dann den Gastzugang benutzen. 

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[Talk-ca] weeklyOSM #517 2020-06-09-2020-06-15

[weeklyteam]

The weekly round-up of OSM news, issue # 517,
is now available online in English, giving as always a summary of a lot of 
things happening in the openstreetmap world:

 https://www.weeklyosm.eu/en/archives/13289/

Enjoy! 

Did you know that you can also submit messages for the weeklyOSM? Just log in 
to https://osmbc.openstreetmap.de/login with your OSM account. Read more about 
how to write a post here: 
http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm 

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-us] weeklyOSM #517 2020-06-09-2020-06-15

[weeklyteam]

The weekly round-up of OSM news, issue # 517,
is now available online in English, giving as always a summary of a lot of 
things happening in the openstreetmap world:

 https://www.weeklyosm.eu/en/archives/13289/

Enjoy! 

Did you know that you can also submit messages for the weeklyOSM? Just log in 
to https://osmbc.openstreetmap.de/login with your OSM account. Read more about 
how to write a post here: 
http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm 

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-GB] weeklyOSM #517 2020-06-09-2020-06-15

[weeklyteam]

The weekly round-up of OSM news, issue # 517,
is now available online in English, giving as always a summary of a lot of 
things happening in the openstreetmap world:

 https://www.weeklyosm.eu/en/archives/13289/

Enjoy! 

Did you know that you can also submit messages for the weeklyOSM? Just log in 
to https://osmbc.openstreetmap.de/login with your OSM account. Read more about 
how to write a post here: 
http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm 

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-br] semanárioOSM Nº 517 2020-06-09-2020-06-15

[theweekly . osm]

Bom dia,

O semanárioOSM Nº 517, o resumo de tudo o que acontece no mundo OpenStreetMap, 
está publicado *em português* : 

https://www.weeklyosm.eu/pb/archives/13289/

Aproveite!

Você sabia que também pode enviar mensagens para o OSM semanal/semanárioOSMſ 
sem ser membro? Basta fazer login em https://osmbc.openstreetmap.de/login com 
sua conta OSM e usar a conta de convidado. Leia mais sobre como escrever um 
post aqui: http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm

semanarioOSM? 
Quem?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Onde?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-pt] semanárioOSM Nº 517 2020-06-09-2020-06-15

[theweekly . osm]

Bom dia,

O semanárioOSM Nº 517, o resumo de tudo o que acontece no mundo OpenStreetMap, 
está publicado *em português* : 

https://www.weeklyosm.eu/pb/archives/13289/

Aproveite!

Você sabia que também pode enviar mensagens para o OSM semanal/semanárioOSMſ 
sem ser membro? Basta fazer login em https://osmbc.openstreetmap.de/login com 
sua conta OSM e usar a conta de convidado. Leia mais sobre como escrever um 
post aqui: http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm

semanarioOSM? 
Quem?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Onde?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt

[Talk-in] weeklyOSM #517 2020-06-09-2020-06-15

[weeklyteam]

The weekly round-up of OSM news, issue # 517,
is now available online in English, giving as always a summary of a lot of 
things happening in the openstreetmap world:

 https://www.weeklyosm.eu/en/archives/13289/

Enjoy! 

Did you know that you can also submit messages for the weeklyOSM? Just log in 
to https://osmbc.openstreetmap.de/login with your OSM account. Read more about 
how to write a post here: 
http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm 

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

[Talk-africa] weeklyOSM #517 2020-06-09-2020-06-15

[weeklyteam]

The weekly round-up of OSM news, issue # 517,
is now available online in English, giving as always a summary of a lot of 
things happening in the openstreetmap world:

 https://www.weeklyosm.eu/en/archives/13289/

Enjoy! 

Did you know that you can also submit messages for the weeklyOSM? Just log in 
to https://osmbc.openstreetmap.de/login with your OSM account. Read more about 
how to write a post here: 
http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm 

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-africa mailing list
Talk-africa@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-africa

Re: [Talk-GB] TfL Cycle Infrastructure Database - matching against OSM

[Mateusz Konieczny via Talk-GB]

21 Jun 2020, 12:07 by p...@trigpoint.me.uk:

> On Sun, 2020-06-21 at 08:42 +0200, Mateusz Konieczny via Talk-GB wrote:
>
>>
>>
>>
>> Jun 21, 2020, 01:21 by list-osm-talk...@cyclestreets.net:
>>
>>>
>>>
>>> On Sun, 26 Apr 2020, Richard Fairhurst wrote:
>>>
 You’ll remember that a couple of weeks ago I posted about the work I’m 
 doing to look at getting the relevant bits of Transport for London’s 
 openly licensed Cycle Infrastructure Database into OSM.

 https://github.com/cyclestreets/tflcid-conversion

 It takes the TfL CID files, compares them against OSM (by making queries 
 against a freshly loaded Postgres database), and outputs a series of files 
 for each datatype, all categorised by the type of editing that will be 
 required to get them into OSM.

>>>
>>> You can now view this converted data as an interactive visualisation at:
>>>
>>> https://bikedata.cyclestreets.net/tflcid2osm/#13.12/51.50426/-0.08725
>>>
>>> Use the "Feature type" drop-down to change the type.
>>>
>>> This shows the results of Richard's excellent scripting to convert the TfL 
>>> CID data to OSM tagging. It hopefully demonstrates the correctness of 
>>> Richard's conversion and the extensiveness of the data. I have also 
>>> included the two TfL photos of each asset.
>>>
>>> NB You can see the original TfL data using the "TfL CID" layer button, and 
>>> OSM data using "OSM" layer button. These are both in the main list of 
>>> cycling data layer buttons on the right-hand side.
>>>
>> https://bikedata.cyclestreets.net/tflcid2osm:type=crossings_junctions/#14.77/51.50656/-0.08864
>> is missing bicycle=yes foot=no intentional? See say 
>> https://www.openstreetmap.org/node/24923378>>  (RWG082685)
>> that seems impassable for pedestrians
>>
>> https://api.cyclestreets.net/v2/infrastructure.image?key=c047ed46f7b50b18=tflcid=RWG082685=1=2=400
>>
>>
> Why?
>
> I cannot seen anything prohibiting pedestrians at that point.
>
> Phil (trigpoint)
>
Is it ok for pedestrians to walk on
the carriageway and cross the road 
together with cyclists in place 
marked by bicycle paintings?___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-se] Kartlägga kollektivtrafik på vatten

[Erik Åman]

Hej!

Jag funderar på att försöka förbättra hur båtlinjer i Stockholms skärgård är 
kartlagda. Det vore intressant att få flera personers syn på hur det görs bäst 
innan jag sätter igång. Det finns nog få områden i världen som har ett lika 
komplicerat kollektivtrafiksystem på vatten, så jag tror att detta är relevant 
att diskutera på den svenska listan.

Det vanliga i OSM är att färjelinjer modelleras med alla attribut på en way. I 
detta fall tror jag dock att man bör använda relationer (enligt Public 
Transport Version 2), även om wiki-sidan [1] varnar att stödet för det är 
begränsat. Försöker man rita ut varje färjelinje separat, blir det på tok för 
gyttrigt (vilket är tydligt exempelvis runt Vaxholm).

Vad jag undrar är till att börja med vilka relationer som bör utnyttja samma 
way. Långdistanstrafiken med stora fartyg över Östersjön är redan till största 
delen i from av relationer, se exempelvis way 140517501 [2] och relationerna 
som använder sig av den. Min intuition säger mig att även om de mindre 
skärgårdsbåtarna till viss del går i samma farled, bör nog inte deras 
relationer använda sig av samma way (som ju räknas som en del av Europaväg 20). 
Men var drar man gränsen?
- När det är olika värden för vilka som får åka med båten, exempelvis 
motor_vehicle=yes/no
- När "operator" eller "network" har olika värden?
En relaterad fråga är vilka attribut som man bör lämna på en way för att 
möjliggöra för datakonsumenter som inte har stöd för relationer.

En annan fundering jag har är var man kan och bör ha förgreningspunkter. Bara 
vid bryggor eller även ute i vattnet (som redan nu är fallet med 
långdistanstrafiken). Mellan Kymmendö och Dalarö [3] finns exempelvis två 
punkter där man kanske eller kanske inte vill ha förgreningar ute på vattnet. 
Söder om Kymmendö (öster om Ornö) finns en färjelinje som trafikerar många 
bryggor, medan den andra bara stannar vid vissa av bryggorna, vilket också kan 
föranleda förgreningspunkter ute på vattnet.

Det finns också fall där olika färjelinjer utan uppenbar anledning kartlagts på 
olika sidor av mindre öar som inte trafikeras, exempelvis nordväst om Sandhamn 
[4]. Förmodligen beror det på väder, trafikförhållanden eller annat just den 
dag då någon lade till just den linjen i OSM. Ska man slå ihop sådana fall till 
en gemensam sträcka som går antingen den vanligaste eller den kortaste vägen? 
Kanske jämförbart med att vid dubbelspårig järnväg lägger man relationen för en 
riktning på det spår som oftast används, även om det inte finns någon garanti 
för att tåget alltid går på det spåret.


[1] https://wiki.openstreetmap.org/wiki/Tag:route%3Dferry
[2] https://www.openstreetmap.org/way/140517501
[3] https://www.openstreetmap.org/#map=14/59.1227/18.4663
[4] https://www.openstreetmap.org/#map=14/59.2951/18.9097


/Erik Åman
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [Talk-GB] TfL Cycle Infrastructure Database - matching against OSM

[Philip Barnes]

On Sun, 2020-06-21 at 08:42 +0200, Mateusz Konieczny via Talk-GB wrote:
> 
> 
> Jun 21, 2020, 01:21 by list-osm-talk...@cyclestreets.net:
> > On Sun, 26 Apr 2020, Richard Fairhurst wrote:
> > > You’ll remember that a couple of weeks ago I posted about the
> > > work I’m doing to look at getting the relevant bits of Transport
> > > for London’s openly licensed Cycle Infrastructure Database into
> > > OSM.
> > > 
> > > https://github.com/cyclestreets/tflcid-conversion
> > > 
> > > It takes the TfL CID files, compares them against OSM (by making
> > > queries against a freshly loaded Postgres database), and outputs
> > > a series of files for each datatype, all categorised by the type
> > > of editing that will be required to get them into OSM.
> > 
> > You can now view this converted data as an interactive
> > visualisation at:
> > 
> > https://bikedata.cyclestreets.net/tflcid2osm/#13.12/51.50426/-0.08725
> > 
> > Use the "Feature type" drop-down to change the type.
> > 
> > This shows the results of Richard's excellent scripting to convert
> > the TfL CID data to OSM tagging. It hopefully demonstrates the
> > correctness of Richard's conversion and the extensiveness of the
> > data. I have also included the two TfL photos of each asset.
> > 
> > NB You can see the original TfL data using the "TfL CID" layer
> > button, and OSM data using "OSM" layer button. These are both in
> > the main list of cycling data layer buttons on the right-hand side.
> https://bikedata.cyclestreets.net/tflcid2osm:type=crossings_junctions/#14.77/51.50656/-0.08864
> is missing bicycle=yes foot=no intentional? See say 
> https://www.openstreetmap.org/node/24923378 (RWG082685)
> that seems impassable for pedestrians
> 
> https://api.cyclestreets.net/v2/infrastructure.image?key=c047ed46f7b50b18=tflcid=RWG082685=1=2=400
> 
Why?

I cannot seen anything prohibiting pedestrians at that point.

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

Re: [Talk-GB] TfL Cycle Infrastructure Database - matching against OSM

[Stephen Colebourne]

On Sun, 21 Jun 2020 at 00:29, Martin - CycleStreets
 wrote:
> Speed bumps:
> https://bikedata.cyclestreets.net/tflcid2osm:type=bumps_road/#14.98/51.47101/-0.02755

There isn't a "bumps_new" filter at present, so it is hard to see what
is to be added. I've already added a lot of traffic calming in my
area, so would want to see what is to be changed.

In general, the work here is amazing, although I can definitely see a
few issues/mismatches.

Stephen

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

Re: [OSM-talk-fr] Cartopartie : comment relever efficacement les horaires des commerces ?

[Arnaud Champollion]

Le 18/06/2020 à 14:43, Yves P. a écrit :

Ok, la carto partie est en ville, donc 3 photos et de bonnes notes devraient le 
faire:)


Merci de tous vos conseils.

La cartopartie s'est très bien passée.

http://www.linux-alpes.org/cartopartie-reussie-a-digne-les-bains/

Nous avons fait des relevés papier pour le mobilier urbain et les noms 
des enseignes : http://linux-alpes.org/osm/notes_18juin.pdf


Et des photos géolocalisées avec Osmand (technique de l'action rapide) + 
import dans JOSM.


Bonne journée,

Arnaud



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

Re: [Talk-it] facebook compra mapillary

[Martin Koppenhoefer]

sent from a phone

> On 21. Jun 2020, at 09:24, Andrea Musuruane  wrote:
> 
> Sinceramente questa isteria non la capisco. Credo che Facebook abbia tutto 
> l'interesse a mantenere il servizio aperto (anzi, ora è più aperto di prima, 
> dato che sono ammessi anche usi commerciali) e a continuare il rapporto con 
> OSM.


se sei un utente Facebook non ti cambia niente, invece se non utilizzi i loro 
servizi, sì, tutto qui.


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

Re: [Talk-it] facebook compra mapillary

[Andrea Musuruane]

On Thu, Jun 18, 2020 at 10:53 PM Martin Koppenhoefer 
wrote:

> Appena saputo, Facebook ha comprato Mapillary. Dopo Openstreetcam (venduto
> da Telenav a Grab) è il secondo acquisto di streetview che non promette
> bene.
>
> Se li avete affidato le vostre foto forse sarebbe una buona idea
> scaricarsi tutto finché si può...
>

Sinceramente questa isteria non la capisco. Credo che Facebook abbia tutto
l'interesse a mantenere il servizio aperto (anzi, ora è più aperto di
prima, dato che sono ammessi anche usi commerciali) e a continuare il
rapporto con OSM.

Ciao,

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

[OSM-talk-fr] Rando VTT — Re: Cartopartie : comment relever efficacement les horaires des commerces ?

[Yves P.]

Bonjour,

> Effectivement, l'ergonomie d'Osmand est horrible.
Je confirme : j'ai effacé par erreur la trace GPS de ma rando VTT d'hier (24 
km, un exploit pour moi)

> Mais on peut positionner une photo, une note audio, une vidéo, 
> - avec toute la précision voulue - bon ok, sauf en rase campagne comme l'a 
> dit Yves ;-)
> - même si on n'a pas de réseau - cartes stockées dans l'ordiphone
> - en 4 clics :
> 1) action rapide
> 2) ajouter une note photo - ou audio, parfois il est plus simple de dire 
> "bâtiment manquant"
> 3) recaler la carte sous le pointeur
> 4) prendre la photo
J'utilisais le support de téléphone Cyclyk . Pas 
pratique pour prendre des photos. Il faut détacher son ordiphone, prendre ses 
photos, le remettre…

Par contre la note audio c'est très pratique :)
"Piste 4x4 descendante à 10h", "Cabane à 3h"…

Sauf… si on efface bêtement sa trace GPS. J'ai essayé de glisser/déposer le 
fichier audio dans JOSM mais il ne sait pas quoi en faire.
(Et pas de coordonnées GPS dans les données EXIF du fichier audio. Idem avec 
OsmTracker)

__
Yves


PS: J'ai essayé rapidement les notes audio dans OsmTracker : elle sont limitées 
à 2 secondes (je n'ai pas trouvé de réglages dans paramètres)

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

Re: [Talk-GB] TfL Cycle Infrastructure Database - matching against OSM

[Mateusz Konieczny via Talk-GB]

Jun 21, 2020, 01:21 by list-osm-talk...@cyclestreets.net:

>
>
> On Sun, 26 Apr 2020, Richard Fairhurst wrote:
>
>> You’ll remember that a couple of weeks ago I posted about the work I’m doing 
>> to look at getting the relevant bits of Transport for London’s openly 
>> licensed Cycle Infrastructure Database into OSM.
>>
>> https://github.com/cyclestreets/tflcid-conversion
>>
>> It takes the TfL CID files, compares them against OSM (by making queries 
>> against a freshly loaded Postgres database), and outputs a series of files 
>> for each datatype, all categorised by the type of editing that will be 
>> required to get them into OSM.
>>
>
> You can now view this converted data as an interactive visualisation at:
>
> https://bikedata.cyclestreets.net/tflcid2osm/#13.12/51.50426/-0.08725
>
> Use the "Feature type" drop-down to change the type.
>
> This shows the results of Richard's excellent scripting to convert the TfL 
> CID data to OSM tagging. It hopefully demonstrates the correctness of 
> Richard's conversion and the extensiveness of the data. I have also included 
> the two TfL photos of each asset.
>
> NB You can see the original TfL data using the "TfL CID" layer button, and 
> OSM data using "OSM" layer button. These are both in the main list of cycling 
> data layer buttons on the right-hand side.
>
https://bikedata.cyclestreets.net/tflcid2osm:type=crossings_junctions/#14.77/51.50656/-0.08864
is missing bicycle=yes foot=no intentional? See say 
https://www.openstreetmap.org/node/24923378 (RWG082685)
that seems impassable for pedestrians

https://api.cyclestreets.net/v2/infrastructure.image?key=c047ed46f7b50b18=tflcid=RWG082685=1=2=400


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

Re: [Talk-GB] TfL Cycle Infrastructure Database - matching against OSM

[Mateusz Konieczny via Talk-GB]

Jun 21, 2020, 01:28 by list-osm-talk...@cyclestreets.net:

>
> Speed bumps:
> https://bikedata.cyclestreets.net/tflcid2osm:type=bumps_road/#14.98/51.47101/-0.02755
>
> Cycle parking:
> https://bikedata.cyclestreets.net/tflcid2osm:type=parking_new/#14.98/51.46059/-0.05586
>
RWG197392 
https://api.cyclestreets.net/v2/infrastructure.image?key=c047ed46f7b50b18=tflcid=RWG197392=1=1=400

looks like bump to me, tagged as hump

RWG999715 has broken images

---

Overall for both - would it be possible to keep images hosted and link them 
with image tag?
Or maybe - upload images to Wikimedia Commons and link them with
wikimedia_commons?

It would make easier to verify what went wrong in case of manual verification.

Is there a plan which tags would be used by changeset itself?
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb