Re: [Talk-us] National Forest boundaries

[stevea]

A refinement, perhaps Bradley and others agree with me, perhaps not.

A USFS NF is a "virtual" multipolygon (not one in OSM, we can get to that 
later) of three kinds of things:

1) An "outer" (but not the biggest one) which is "the enclosing land which USFS 
manages, except for inholdings, below,"
2) Zero to many "inner" polygons, representing inholdings (and with the usual 
"hole" semantic of exclusion from 1), above and
3) An even LARGER and ENCLOSING of 1) "outer" which Congress declares is the 
geographic extent to which USFS may or might "have influence to someday manage."

If we ignore 3) as "not real, but rather aspirational or in the future rather 
than the present, and certainly not on-the-ground" then an OSM multipolygon 
consists of simply 1) plus 2).

Yes?

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

Re: [OSM-talk-fr] Marseille : le cadastre ça n'existe plus ?

[FR via Talk-fr]

issue closed 7 hours ago

Merci Frédéric, je suis toujours autant épatée par ta virtuosité

Bonne journée

FR

Le 24/06/2020 à 14:45, FR via Talk-fr a écrit :

Merci Christian

C'est bien un problème de PLM

https://github.com/osm-fr/infrastructure/issues/199

Franssoize (github n'a pas voulu de ma cédille)

Le 24/06/2020 à 12:16, Christian Quest a écrit :

Ce doit être un problème lié aux arrondissements...

Peux-tu vérifier sur Lyon et Paris ?

Si tu as un compte github, tu peux ouvrir une issue sur 
https://github.com/osm-fr/infrastructure/issues/new



Le 23/06/2020 à 19:03, FR via Talk-fr a écrit :

Bonsoir
Pas moyen d'avoir le cadastre marseillais dans JOSM ni dans le menu 
Imagerie ni dans le menu Cadastre : "la commune demandée n'existe 
pas..."

Alors que toutes les communes périphériques sont OK
À l'aide ;-)
FR 




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

Re: [Talk-us] National Forest boundaries

[stevea]

On Jun 24, 2020, at 9:40 PM, Bradley White  wrote:
> NF congressionally designated boundary, minus private inholdings (more
> specifically, non-USFS-owned land), gives you the boundary of land
> that is actually managed and protected by the USFS. This boundary
> should be tagged with 'protect_class=6'. USFS owned land is always a
> subset of this congressional boundary (I suspect it is, in all cases
> in the US, a proper subset). Subtracting these private inholdings is
> generally going to change the shape of the 'outer' way such that it no
> longer is the same as the "designated" boundary.

That really helps; thank you!  I think I still need to do some imagination 
exercises here, and maybe see some examples (in a JOSM buffer, in the real 
world...) and it will fully crystallize in my mind.  And, if true, the phrase 
"proper subset" helps, as well.

>> My slight disagreement with Bradley is as above:  I don't think we should 
>> put a "naked" (missing admin_level) boundary=administrative tag on these, it 
>> simply feels wrong to do that.  (I READ the point that these are 
>> "Congressionally designated" and that SEEMS administrative...but, hm...).
> 
> I wasn't clear in what I meant by suggesting 'boundary=administrative'
> tagging here - I don't think we should tag "declared" boundaries
> 'boundary=administrative' with no 'admin_level'. This is simply the
> closest widely-used tag that comes close to representing what this
> "declared" boundary actually means. This is also why I suggest we
> think about not including it at all in OSM; should we also start
> adding boundaries for interstate USFS administrative regions (an
> 'admin_level', for lack of a better term, more general than a NF
> boundary), as well as ranger districts within each national forest?
> 
> The real, on-the-ground objects of importance here are the plots of
> land that are actually owned and operated by the USFS, not an
> administrative boundary that declares where each national forest *may*
> legally be authorized to own and manage land, and that is not
> surveyable on the ground.

We were doing great there, then I think my (admonishment?  might be too strong) 
way of expressing "owned and operated by the USFS" is technically, accurately 
stated as "owned by the People, managed / operated specifically by the USFS."  
If you can agree with me there, I think we can get even closer.  If not, that 
seems like a central core of the snarl in at least my understanding.

There are three states we seem to be trying to capture here:  1) land Congress 
declares is "managed and protected" by USFS, which OSM represents with an 
enclosing "outer."  2)  Excluded from 1) are inholdings, which have role 
"inner" in the multipolygon.  3) Land Bradley called "owned and operated by 
USFS" (but which I say is owned by the People and operated by the USFS).

See, 1) and 3) seem like the same thing to me.  Why would Congress say what 
Bradley mentions first (at the top of this post) is "managed and protected by 
USFS" (minus inholdings) and yet there is something "owned by USFS" (when the 
government owns land, the People own the land; the government agency is 
operator FOR the People) which I seem to confuse with 3).  Am I doing that?  Is 
Bradley?  Is Congress?  Is it about ownership and operator status being 
confused in my mind?

I'm not stupid, I'm getting closer and I'm grateful for what I hope isn't 
confused blather.

Thankful for talk-pages, thankful for the good talk that happens within them,
SteveA
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] National Forest boundaries

[Bradley White]

> However, I'm not exactly sure how the outer polygons found in NFs differ from 
> either the "Congressional" boundary or the one Bradley says he would tag 
> "boundary=administrative" (and I don't think we should tag it that, 
> especially while excluding a specific value for admin_level), but I'm willing 
> to listen to more discussion about what this "different from Congressional" 
> boundary is and how the two differ.  Apologies if that isn't clear, I'm doing 
> my best, but I remain unclear on some concepts here.

NF congressionally designated boundary, minus private inholdings (more
specifically, non-USFS-owned land), gives you the boundary of land
that is actually managed and protected by the USFS. This boundary
should be tagged with 'protect_class=6'. USFS owned land is always a
subset of this congressional boundary (I suspect it is, in all cases
in the US, a proper subset). Subtracting these private inholdings is
generally going to change the shape of the 'outer' way such that it no
longer is the same as the "designated" boundary.

> My slight disagreement with Bradley is as above:  I don't think we should put 
> a "naked" (missing admin_level) boundary=administrative tag on these, it 
> simply feels wrong to do that.  (I READ the point that these are 
> "Congressionally designated" and that SEEMS administrative...but, hm...).

I wasn't clear in what I meant by suggesting 'boundary=administrative'
tagging here - I don't think we should tag "declared" boundaries
'boundary=administrative' with no 'admin_level'. This is simply the
closest widely-used tag that comes close to representing what this
"declared" boundary actually means. This is also why I suggest we
think about not including it at all in OSM; should we also start
adding boundaries for interstate USFS administrative regions (an
'admin_level', for lack of a better term, more general than a NF
boundary), as well as ranger districts within each national forest?

The real, on-the-ground objects of importance here are the plots of
land that are actually owned and operated by the USFS, not an
administrative boundary that declares where each national forest *may*
legally be authorized to own and manage land, and that is not
surveyable on the ground.

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

Re: [Talk-us] Is summit register something that is often found in USA mountains?

[Tod Fitch]

Summit registers are fairly common on the higher peaks in California.

> On Jun 24, 2020, at 12:07 PM, Mike Thompson  wrote:
> 
> 
> 
> On Wed, Jun 24, 2020 at 1:03 PM Mateusz Konieczny via Talk-us 
> mailto:talk-us@openstreetmap.org>> wrote:
> >
> > Is summit register something that is often found in USA mountains?
> At least in Colorado they are.  Nowadays they are often pieces of pvc pipe.
> 
> Mike
> 
> 
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us



signature.asc
Description: Message signed with OpenPGP
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] relations on which thematic data can be connected? eg internet availabilty byt zipcode

[Clifford Snow]

Ray,
As  you learned from Spencer Alves, postal codes are not areas. As far as I
know there are no zip code areas in OSM. I would recommend using QGIS and
Postgis to construct your queries using OSM and TIGER zip code boundaries.

Are you looking for any broadband connectivity, just cellular, DSL, fiber,
satellite, or a combination of all of them? My experience is that cellular
maps often overstate their reach. Satellite internet service isn't really
that great because of the lag time involved. (Upcoming low earth orbit
communications satellites promise break thoughts )

Your project is interesting. I hope to read about your conclusions. BTW - I
do have friends that only get internet service via their cell phones.
Another even used to live off the grid on purpose. When we went looking for
a place in rural Washington, we definitely had to exclude places that
either didn't have internet service or the cell service was non-existent.

Good luck,
Clifford



On Wed, Jun 24, 2020 at 2:33 PM Ray Kiddy  wrote:

> Hello -
>
> I am interested in where people in the US lack internet connectivity and
> I keep thinking that I should be able to use OSM for some part of this.
>
> I am recalling (perhaps not accurately) that connectivity information is
> published by the FCC and I think that at least some of the information
> is per zipcode.
>
> This led me into a bit of a rat hole as I sought to find out if there
> are relations for zipcodes in the US. Does anyone know? I know that
> TIGER data defines lines that bound zipcodes. But can one craft a query
> that maps just the edges of a zipcode area? Are there then relations
> defined for those edges?
>
> I can keep thematic data on my own database but, so far, I do it by
> linking directly to a relation or way. If it had to be a set of
> relations, that would be unfortunate, but possible. But I am not seeing
> how to make the queries.
>
> Any ideas?
>
> cheers - ray
>
>
> ___
> 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-us] relations on which thematic data can be connected? eg internet availabilty byt zipcode

[Spencer Alves]

Zip Codes are Not Areas
http://www.georeference.org/doc/zip_codes_are_not_areas.htm
Specifically for Zip codes, the best you could do is query for addr:postcode.

> On Jun 24, 2020, at 2:33 PM, Ray Kiddy  wrote:
> 
> Hello -
> 
> I am interested in where people in the US lack internet connectivity and I 
> keep thinking that I should be able to use OSM for some part of this.
> 
> I am recalling (perhaps not accurately) that connectivity information is 
> published by the FCC and I think that at least some of the information is per 
> zipcode.
> 
> This led me into a bit of a rat hole as I sought to find out if there are 
> relations for zipcodes in the US. Does anyone know? I know that TIGER data 
> defines lines that bound zipcodes. But can one craft a query that maps just 
> the edges of a zipcode area? Are there then relations defined for those edges?
> 
> I can keep thematic data on my own database but, so far, I do it by linking 
> directly to a relation or way. If it had to be a set of relations, that would 
> be unfortunate, but possible. But I am not seeing how to make the queries.
> 
> Any ideas?
> 
> cheers - ray
> 
> 
> ___
> 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-us] relations on which thematic data can be connected? eg internet availabilty byt zipcode

[Ray Kiddy]

Wow. Bizarre, but good to know. Yes, I _always_ have thought that 
zipcodes partition land areas.


Now I have to wonder if ZCTAs are still around and if they are mapped. I 
expect not.


much thanx - ray

On 6/24/20 2:39 PM, Spencer Alves wrote:

Zip Codes are Not Areas
http://www.georeference.org/doc/zip_codes_are_not_areas.htm
Specifically for Zip codes, the best you could do is query for addr:postcode.


On Jun 24, 2020, at 2:33 PM, Ray Kiddy  wrote:

Hello -

I am interested in where people in the US lack internet connectivity and I keep 
thinking that I should be able to use OSM for some part of this.

I am recalling (perhaps not accurately) that connectivity information is 
published by the FCC and I think that at least some of the information is per 
zipcode.

This led me into a bit of a rat hole as I sought to find out if there are 
relations for zipcodes in the US. Does anyone know? I know that TIGER data 
defines lines that bound zipcodes. But can one craft a query that maps just the 
edges of a zipcode area? Are there then relations defined for those edges?

I can keep thematic data on my own database but, so far, I do it by linking 
directly to a relation or way. If it had to be a set of relations, that would 
be unfortunate, but possible. But I am not seeing how to make the queries.

Any ideas?

cheers - ray


___
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

[Talk-us] relations on which thematic data can be connected? eg internet availabilty byt zipcode

[Ray Kiddy]

Hello -

I am interested in where people in the US lack internet connectivity and 
I keep thinking that I should be able to use OSM for some part of this.


I am recalling (perhaps not accurately) that connectivity information is 
published by the FCC and I think that at least some of the information 
is per zipcode.


This led me into a bit of a rat hole as I sought to find out if there 
are relations for zipcodes in the US. Does anyone know? I know that 
TIGER data defines lines that bound zipcodes. But can one craft a query 
that maps just the edges of a zipcode area? Are there then relations 
defined for those edges?


I can keep thematic data on my own database but, so far, I do it by 
linking directly to a relation or way. If it had to be a set of 
relations, that would be unfortunate, but possible. But I am not seeing 
how to make the queries.


Any ideas?

cheers - ray


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

Re: [Talk-us] National Forest boundaries

[stevea]

I (momentarily?) recede from my "watching mode" in this thread to offer my 
agreement with Mike and to reiterate a slight disagreement with Bradley (or 
maybe to ask Bradley and especially the wider list here for clarification), as 
while it seems we get closer to a "more definitive" way to tag NF boundaries, 
this discussion doesn't seem close to having yielded a complete agreement 
(yet).  Nor even full understanding, at least on my part.

My agreement with Mike is noticing that (in California only), CPAD data for NFs 
are excellent quality; I believe OSM users in California should feel 
comfortable using them for NFs, as when I look at the "SuperUnit" version of 
CPAD's release of these (there are also "Unit" and "Holdings," a sort of 
"parcel-level") NFs invariably have a big, SINGLE outer polygon (and up to 
hundreds of inners).  I wrote wiki on how CPAD data might be best utilized in 
OSM, see https://wiki.osm.org/wiki/California/Using_CPAD_data .  However, I'm 
not exactly sure how the outer polygons found in NFs differ from either the 
"Congressional" boundary or the one Bradley says he would tag 
"boundary=administrative" (and I don't think we should tag it that, especially 
while excluding a specific value for admin_level), but I'm willing to listen to 
more discussion about what this "different from Congressional" boundary is and 
how the two differ.  Apologies if that isn't clear, I'm doing my best, but I 
remain unclear on some concepts here.

My slight disagreement with Bradley is as above:  I don't think we should put a 
"naked" (missing admin_level) boundary=administrative tag on these, it simply 
feels wrong to do that.  (I READ the point that these are "Congressionally 
designated" and that SEEMS administrative...but, hm...).  One major problem I 
have is that we're multiplying polygons (by two) here for a SINGLE national 
forest.  Isn't there a way we can keep all these data in a single relation?  
Yes, inner can remain as the right role for inholdings, maybe outer is better 
placed on either "Congressional" or "the other one that is more on-the-ground", 
maybe we coin a third role ("congressional"?) for that one, allowing us to keep 
the "bigger, enclosing" polygons in a single multipolygon relation, which I 
think is an "OSM-sane" thing to do.

Summarizing, CPAD data for California:  very good.  Maybe even excellent, 
though I think some examination of the differences of NFs between the 
SuperUnit, Unit and Holdings flavors of CPAD data is a very good idea that 
somebody (a Californian OSM multipolygon and shapefile jockey who knows 
something about national forest structure) should take some time to examine.  
Differences between "the two" kinds of "more outer" multipolygon boundaries of 
NFs?  Murky, well, remaining somewhat murky in my mind, at least how these 
should best logically be expressed by OSM relations.  The discussion is good, I 
simply reiterate my "I still don't quite understand all of this very well" here 
and now.  Brian seems to agree with me and I don't think I'm alone.  Let's keep 
the momentum rolling until more / most of this achieve that "a-ha" moment as to 
how OSM should best express NFs with multipolygons.

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

Re: [OSM-talk-fr] feed mastodon cassé sur osm.fr

[Donat ROBAUX]

Hello,

Eh oui Florian, on en a bien parlé ;)
Pour ceux qui s'intéressent au site internet, un canal Framateam est
ouvert: https://framateam.org/osm-france/channels/site-internet

Par ailleurs, tous les contributeurs sont les bienvenus pour proposer des
articles au blog du site. On vous ouvre un accès "rédacteur" et c'est parti.

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

Re: [Talk-de] "Driveway" als Fläche üblich/erlaubt?

[Hubert87]

Dem würde ich widersprechen.
hw=* + area=yes sollte IMO nur da verwendet werden, wo eine
Bewegungsrichtung nicht sinnvoll ist. z.B. Marktplätze. Dann aber ohne
zusätzlichem hw=* (vom gleichen Typ) "quer" über diese Fläche.

@Manuel: Bitte schau mal nach, ob ggf area:highway etwas für Dich ist.
Wird aber noch nicht auf osm.org gerendert, aber das steht sowieso auf
einer anderen Seite.

VG
Hubert87

Am 24.06.2020 um 09:18 schrieb Florian Lohoff:

On Tue, Jun 23, 2020 at 07:18:37PM +0200, Manuel Reimer wrote:

Hallo,

bei uns gibt es in der Nähe mehrere Ansammlungen von Garagen. Die Zufahrten
dazu habe ich alle mit "highway=service" und "service=driveway" eingetragen.
Allerdings entspricht das eigentlich nicht den örtlichen Gegebenheiten.
Für's Routing wäre es nicht falsch (sofern es wirklich jemand nötig hat sich
bis in seine Garage routen zu lassen) aber eigentlich ist die ganze Fläche
vor und zwischen den Garagen-Reihen gepflastert. Man könnte einen beliebigen
Weg über dieses Pflaster zur Garage nehmen.

Wäre es nun richtig, bzw. sinnvoll die Fläche *zusätzlich* zu den Wegen mit
"area=yes" und den gleichen Tags wie für die Wege zu versehen um
darzustellen das die ganze Fläche "driveway" ist?

Falsch ist das nicht. Für das Routing ändert das nichts. Sieht vielleicht
nur "hübscher" in der Karte aus. Ich mache sowas nicht weil ich immer
denke "je mehr Objekte des komplizierter das zu maintainen". Also trage
ich Zeugs ein was FÜR MICH Sinn ergibt.

Flo

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

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

Re: [Talk-us] Is summit register something that is often found in USA mountains?

[Mike Thompson]

Another feature that is often found at summits around here is a roughly
constructed shelter, such as:
https://images.app.goo.gl/KogTgXChrGx93Ab96

These have been made over the years by various hikers stacking rocks in a
semicircle.  One can sit down inside them and obtain some shelter from the
wind.  Some summits have multiple such shelters.

Mike

On Wed, Jun 24, 2020 at 1:07 PM Mike Thompson  wrote:

>
>
> On Wed, Jun 24, 2020 at 1:03 PM Mateusz Konieczny via Talk-us <
> talk-us@openstreetmap.org> wrote:
> >
> > Is summit register something that is often found in USA mountains?
> At least in Colorado they are.  Nowadays they are often pieces of pvc pipe.
>
> Mike
>
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] feed mastodon cassé sur osm.fr

[Florian LAINEZ]

OK j'ai continué à bosser sur le site :
-j'ai rajouté des images pour les derniers articles dans la partie actu
-j'ai simplifié le footer
-j'ai corrigé un peu le wording de la FAQ
-j'ai rajouté des liens vers nos médias sociaux sur la page "contact"
-j'ai repassée la page "presse" en brouillon : elle n'est pas terminée
(d'ailleurs, si ça tente quelqu'un, on aurait sûrement besoin d'un dossier
de presse générique ...)
-j'ai descendu la photo sur la page d'accueil

Je tique avec le sous-titre "La communauté et des ressources à portée de
clic" qui ne me semble pas du tout résumer la mission de l'asso.
Je ne me souviens pas d'avoir discuté de ce point lors du lancement du
site, je me permet donc de remettre ça sur le tapis.
Auparavant on avait "cartographier le monde, rue après rue".
Mes propositions :
- Cartographie collaborative Libre
- Cartographie collaborative mondiale
- LA carte ouverte
- La carte ouverte que tout le monde utilise sans le savoir
Je pense que ça vaudrait le coup de se pencher sérieusement sur quel
pourrait être notre slogan, non ?

Le mer. 24 juin 2020 à 12:45, Christian Quest  a
écrit :

> Le 23/06/2020 à 18:23, Cédric Frayssinet a écrit :
> >>
> >> Est-ce que le compte Mastodon de l'asso est vraiment utilisé ? Je
> >> pose la question de bonne foi et sans à-priori.
> >> Je vais mettre les pieds dans le plat mais  ne devrions-nous
> >> pas plutôt mettre Twitter ?
> >
> >
> > Euh non :) AMHA, il faudrait pouetter puis crossposter automatiquement
> > sur Twitter et pas l'inverse, je ne développe pas mais faut savoir
> > aussi être cohérent :) D'ailleurs le crosspost Twitter > Masto est
> > très mal vu.
> >
> > Cédric
> >
> Oui, actuellement on a du cross-post twitter vers mastodon... bien plus
> simple à faire
>
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 

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

Re: [Talk-us] Is summit register something that is often found in USA mountains?

[Mike Thompson]

On Wed, Jun 24, 2020 at 1:03 PM Mateusz Konieczny via Talk-us <
talk-us@openstreetmap.org> wrote:
>
> Is summit register something that is often found in USA mountains?
At least in Colorado they are.  Nowadays they are often pieces of pvc pipe.

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

[Talk-us] Is summit register something that is often found in USA mountains?

[Mateusz Konieczny via Talk-us]

Is summit register something that is often found in USA mountains?

("A summit book or summit register is a record of visitors to the summit
of a mountain. It is usually enclosed in a weatherproof, animalproof metal 
canister.")

I am asking as I plan to implement summit register part of 
https://github.com/westnordost/StreetComplete/issues/561 and I wonder
whatever it makes sense to ask this question in USA.

So far this kind of object is not mapped at all in USA ( 
https://taginfo.openstreetmap.org/keys/summit%3Aregister#map )
but https://en.wikipedia.org/wiki/Summit_register claims
"The Sierra Club places official registers on many mountains
throughout California and the United States." (with quite weak source)
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-de] Position des FOSSGIS e.V. zu bezahlten Kräften in der OSMF

[Michael Reichert]

Hallo,

Am 25.05.20 um 22:14 schrieb Michael Reichert:
> auf der Mailingliste OSMF-Talk gab es, angestoßen vom OSMF-Vorstand, vor
> etwa zwei Wochen eine Diskussion über bezahlte Kräfte in der OSM
> Foundation [1]. Wir haben heute Abend auf dem FOSSGIS-OSMF-Stammtisch
> lange über bezahlte Kräfte in der OSMF diskutiert.
> 
> Konsens der Diskussion war:
> 
> - Für die Vergabe von Tätigkeiten an bezahlte Kräfte, sollte der
>   Vorstand vorher eine Tätigkeitsbeschreibung aufstellen und
>   sicherstellen, dass die Tätigkeit in die Zuständigkeit der OSMF fällt
>   und kein Engagement Freiwilliger verdrängt wird.
> - Die Mitglieder sollten den Grundsätzen der Personalpolitik zustimmen.
>   Sie sollte der Schaffung neuer Stellen auf Basis der
>   Tätigkeitsbeschreibung zustimmen.
> - Die OSMF soll als Arbeitgeber/Auftraggeber ihrer sozialen
>   Verantwortung gegenüber den für sie Tätigen gerecht werden.
> 
> Eine gemeinsame Position des FOSSGIS e.V. als Local Chapter der OSMF in
> Deutschland zu diesem Thema wird Tagesordnungspunkt auf der nächsten
> Vorstandsitzung des FOSSGIS e.V. am Dienstag, den 1. Juni 2020 um 20:00
> Uhr auf dem Mumble-Server podcast.openstreetmap.de sein.
> 
> Welche Meinung habt ihr zu bezahlten Kräften in der OSMF dazu? Stimmt
> ihr dem obigen Konsens zu? Oder seid ihr anderer Meinung?
Vielen Dank an alle, die sich an der Diskussion beteiligt haben.

Der FOSSGIS-Vorstand hat die oben zitierten Grundsätze gut geheißen.
Christoph Hormann hat eine Textfassung vorbereitet, die wir auf dem
letzten FOSSGIS-OSMF-Stammtisch leicht modifiziert haben. Details zum
Vorgang könnt ihr in den Protokollen nachlesen.

https://www.fossgis.de/verein/vorstand/2020-06-02-protokoll-vorstandssitzung/
https://www.fossgis.de/wiki/FOSSGIS-OSMF-Stammtisch/2020-06-18

Das Positionspapier ist jetzt auf der FOSSGIS-Website veröffentlicht
worden und die Position den Abonnenten der Mailingliste OSMF-Talk
mitgeteilt worden (dort mit halbautomatischer englischer Übersetzung).

https://www.fossgis.de/community/stammtische/bezahlte_kraefte
https://lists.openstreetmap.org/pipermail/osmf-talk/2020-June/006927.html

Der nächste FOSSGIS-OSMF-Stammtisch findet außer der Reihe schon morgen
Abend um 20:00 Uhr per Mumble-Voicechat statt. Ihr seid alle herzlich
eingeladen. Es ist ein virtueller Plaudertreff mit Protokoll, keine
förmliche Arbeitsgruppe.

Viele Grüße

Michael



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-us] National Forest boundaries

[Brian M Hamlin]

seconded stevea -- very interesting and cogent, definitely reading these 
National Forest expositions


best regards from Berkeley, California   --Brian M Hamlin MAPLABS



___
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 24. Jun 2020, at 17:27, Andrea Albani  wrote:
> 
> Ovviamente Facebook produce SDK per qualsiasi piattaforma.


esatto, non è limitato to Android, anche su iOS c’è l’SDK di Facebook. Con un 
developer proxy protresti vedere se le tue app fanno chiamate FB “a casa”. In 
teoria, se il publisher è regolare, dovrebbe indicarlo nella privacy policy (ma 
non è scontato che lo faccia). Chi fa pubblicità per la sua app su Facebook 
quasi sicuramente ha integrato anche l’SDK, per tracciare le istallazioni e 
utilizzi.
Sul computer puoi facilmente bloccare il traffico verso tutti i domini facebook 
(sperando che usano solo domini che sono palesemente di facebook), ma sui 
cellulari non è possibile.

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

Re: [Talk-br] Nova proposta de classificação viária - Votação encerrada

[santamariense]

> Acho que a proposta base pode ser considerada aprovada e os questionamentos
> levantados devem ser discutidos e votados separadamente. Alguns itens da
> proposta também precisa de ajustes na terminologia (que não mudam o sentido
> da proposta, mas deixam ela mais uniforme):

Acho que é um bom caminho. Dar como aprovado e passar a discutir e
votar os pormenores para então consolidar.

> "se a proposta obteve apoio suficiente, seu status pode ser alterado para
> aprovada. Uma regra geral para 'apoio suficiente' é 8 votos unânimes de
> aprovação ou pelo menos 10 votos com mais de 74% de aprovação" (tradução
> livre).

Ele também diz que outros fatores podem ser considerados como no caso
de uma feature já estar em uso, o que é o nosso caso. A gente não está
criando uma nova tag, apenas está ajustando o conceito de tags já
existentes de modo a seguir uma padronização internacional. Ao meu
ver, mesmo quem votou contra a proposta ainda assim está seguindo por
este caminho, apesar de discordar em algumas questões pontuais, que os
levaram a discordar do todo.

> No artigo sobre o processo de votação também diz: "todas as sugestões
> devem ser levadas em consideração antes de uma proposta ser aprovada
> ou rejeitada, a fim de resolver quaisquer deficiências na proposta
> original (se houver)." Eu acho que isso que pode estar faltando nesse
> caso.

Concordo. E na verdade a discussão sempre seguirá conforme for se
observando pequenas peculiaridades/controvérsias ao mapear.

> No mesmo artigo, há uma seção para o período "pós-voto" (post-vote). O
> template Proposal Page, [3] usado na maioria dos artigos anglófonos de
> propostas, suporta o valor "Post-Vote" para o campo status. Se vocês
> procurarem no wiki por "Post-Vote," vão encontrar vários artigos de
> propostas com uma seção "Post-Vote" onde são discutidos os próximos
> passos, onde se discute como tratar dos apontamentos feitos por quem
> votou. Me parece que estamos exatamente nesta fase.

Concordo.

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

Re: [Talk-it] facebook compra mapillary

[Andrea Albani]

Il giorno lun 22 giu 2020 alle ore 17:20 mbranco2  ha
scritto:

> . e anche se fosse, non mi preoccupa visto che io l'account FB non ce
> l'ho... :-)
>

half-OT
... magari hai un Android e qualche app che usa (a tua insaputa) il
Facebook SDK, ovvero basta un ID univoco per tracciarti e se poi non è
associato ad un nome e cognome di un account FB poco importa.. la
profilazione è comunque servita. Ovviamente Facebook produce SDK per
qualsiasi piattaforma.

Privacy International aveva fatto una bella presentazione in merito alla 3C
conference del 2018 (report e video al link sotto)

Ciao

https://privacyinternational.org/report/2647/how-apps-android-share-data-facebook-report
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] maglietta SotM2020

[Martin Koppenhoefer]

sono britanniche

sent from a phone

> On 24. Jun 2020, at 15:42, Matteo Zaffonato  wrote:
> 
> 
> Il 24/06/2020 12:58, Martin Koppenhoefer ha scritto:
>> Vi segnalo che potete ordinare le magliette per SotM qui se volete:
>> 
>> I've created a UK (and Europe) option for the shirt...
>> https://wiki.openstreetmap.org/wiki/State_of_the_Map_2020/Tshirt_shop_organization#Europe
>> 
>> Ciao Martin 
>> 
>> sent from a phone
>> 
>> 
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
> Le taglie sono europee o americane?
> 
> Ciao, grazie
> Matteo
> 
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-us] National Forest boundaries

[Mike Thompson]

On Tue, Jun 23, 2020 at 7:35 PM brad  wrote:
>
>  There are a few cases where property owners have put up illegal, or very
misleading signs.
I have come across this too.  The signs are on private property, but face
you as you are traveling on a legal FS road and looking straight ahead.  It
makes it seem like the road is private from that point forward if you don't
know otherwise.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-it] maglietta SotM2020

[Matteo Zaffonato]

Il 24/06/2020 12:58, Martin Koppenhoefer ha scritto:

Vi segnalo che potete ordinare le magliette per SotM qui se volete:


I've created a UK (and Europe) option for the shirt...

https://wiki.openstreetmap.org/wiki/State_of_the_Map_2020/Tshirt_shop_organization#Europe


Ciao Martin


sent from a phone

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


Le taglie sono europee o americane?

Ciao, grazie
Matteo

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

Re: [OSM-talk-fr] Marseille : le cadastre ça n'existe plus ?

[FR via Talk-fr]

Merci Christian

C'est bien un problème de PLM

https://github.com/osm-fr/infrastructure/issues/199

Franssoize (github n'a pas voulu de ma cédille)

Le 24/06/2020 à 12:16, Christian Quest a écrit :

Ce doit être un problème lié aux arrondissements...

Peux-tu vérifier sur Lyon et Paris ?

Si tu as un compte github, tu peux ouvrir une issue sur 
https://github.com/osm-fr/infrastructure/issues/new



Le 23/06/2020 à 19:03, FR via Talk-fr a écrit :

Bonsoir
Pas moyen d'avoir le cadastre marseillais dans JOSM ni dans le menu 
Imagerie ni dans le menu Cadastre : "la commune demandée n'existe pas..."

Alors que toutes les communes périphériques sont OK
À l'aide ;-)
FR



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

[Talk-it] maglietta SotM2020

[Martin Koppenhoefer]

Vi segnalo che potete ordinare le magliette per SotM qui se volete:

I've created a UK (and Europe) option for the shirt...
https://wiki.openstreetmap.org/wiki/State_of_the_Map_2020/Tshirt_shop_organization#Europe

Ciao Martin 

sent from a phone___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] feed mastodon cassé sur osm.fr

[Christian Quest]

Le 23/06/2020 à 18:23, Cédric Frayssinet a écrit :


Est-ce que le compte Mastodon de l'asso est vraiment utilisé ? Je 
pose la question de bonne foi et sans à-priori.
Je vais mettre les pieds dans le plat mais  ne devrions-nous 
pas plutôt mettre Twitter ?



Euh non :) AMHA, il faudrait pouetter puis crossposter automatiquement 
sur Twitter et pas l'inverse, je ne développe pas mais faut savoir 
aussi être cohérent :) D'ailleurs le crosspost Twitter > Masto est 
très mal vu.


Cédric


Oui, actuellement on a du cross-post twitter vers mastodon... bien plus simple 
à faire


--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Marseille : le cadastre ça n'existe plus ?

[Christian Quest]

Ce doit être un problème lié aux arrondissements...

Peux-tu vérifier sur Lyon et Paris ?

Si tu as un compte github, tu peux ouvrir une issue sur 
https://github.com/osm-fr/infrastructure/issues/new



Le 23/06/2020 à 19:03, FR via Talk-fr a écrit :

Bonsoir
Pas moyen d'avoir le cadastre marseillais dans JOSM ni dans le menu 
Imagerie ni dans le menu Cadastre : "la commune demandée n'existe pas..."

Alors que toutes les communes périphériques sont OK
À l'aide ;-)
FR


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


--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] BANO ça n'existe plus ?

[Jacques Lavignotte]

Le 24/06/2020 à 11:21, Vincent de Château-Thierry a écrit :


Désolé Jacques pour la chronologie. Je confirme que c'est sur (le haut de) ma 
pile de choses à faire.


J'y survivrai ;)

J.

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

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

Re: [OSM-talk-fr] Bano v2

[Marc M.]

Bonjour,

Le 24.06.20 à 09:40, Cyrille37 OSM a écrit :
> Le 07/05/2020 à 10:59, Marc M. a écrit :
>> la veille base dont il dépend ne se met plus à jour
>> depuis le 11 avril, et donc les fichiers produits ne le sont pas.
> 
> C'est largement suffisant pour être très utile.

ce n'est pas moi qu'il faut convaincre :)

hélas le serveur n'a pas l'option upgrade
--inutilement-différent-des-autres-mais-fix-sans-que-j-y-passse-des-heures
:)
la culture du "mutualisation minimale" a un prix humain et fonctionnel,
les mêmes choix conceptuels sont discutés pour la v2, avec donc
les mêmes conséquences tant à court terme (l'install) qu'à long terme
(la maintenance)

Merci à Jacques d'avoir trouvé une des causes (fichier de style
contenant une ip publique en dur, hors celle-ci ont changés récemment)
j'ai appliqué le correctif.

a vu de nez, il y en a au moins encore 2 (droit sur la bdd, https)

Cordialement,
Marc

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

Re: [OSM-talk-fr] BANO ça n'existe plus ?

[Vincent de Château-Thierry]

Bonjour,

> De: "Christian Quest" 
> 
> La bascule BANOv1/v2 ne s'est pas suffisamment coordonnée pour éviter
> ce "trou" et cela s'ajoute à des service installés depuis des années,
> qui sont souvent trop stables et donc on laisse la maintenance un peu
> trop en friche ;)
> 
> 
> Le feuille de style qui l'alimente est ici:
> https://github.com/osm-fr/bano-cartocss
> 
> Les requêtes SQL sont à revoir pour s'adapter à BANOv2, ce que vdct
> comptais faire...

Désolé Jacques pour la chronologie. Je confirme que c'est sur (le haut de) ma 
pile de choses à faire.

vincent

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

Re: [OSM-talk-fr] cadastre.openstreetmap.fr ???

[Cyrille37 OSM]

Génial, Merci !
Cyrille37.

Le 24/06/2020 à 09:43, Marc M. a écrit :

et pour fêter cela, la configuration a été corrigée
pour http://cadastre.openstreetmap.fr
(adaptation du fichier de config suite à la maj
d'il y a 2-3 jours. c'était passé inapercu).

Cordialement,
Marc


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

Re: [OSM-talk-fr] Data OSM - VisuOSM

[Cyrille37 OSM]

J'aime beaucoup "VisuOSM" pour "Visualisation des données OSM" :-)

Cyrille37.



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

Re: [Talk-GB] Documenting tagging practice for place nodes in London

[Russ Garrett]

On Wed, 24 Jun 2020 at 09:19, Jez Nicholson  wrote:
> I take it that these names are used by Nominatim to assist with search. I 
> know it's another form of tagging-for-the-renderer, but do you know 
> how/whether changes affect it?

I'm not especially familiar with the internals of Nominatim but I
think for most purposes it actually prefers the page rank on Wikipedia
(discovered via the wikidata tag if provided) for ranking place nodes,
rather than the actual value of the place tag (which makes sense as
the usage tends to be inconsistent anyway).

https://nominatim.org/release-docs/develop/develop/Ranking

-- 
Russ Garrett
r...@garrett.co.uk

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

Re: [OSM-talk-fr] Data OSM

[Romain MEHUT]

Bonjour,

Je fais suivre quelques observations que j'ai reçues autour de moi :

- Ca ne fonctionne pas derrière un proxy/pare-feu d'entreprise, 
peut-être à cause du fait que la connexion n'est pas protégée (httpS).
- les termes sonnent très "géomatique"et est-ce qu'on est obligé de 
mettre "géo" devant les mots étant donné qu'on sait déjà dans quelle 
genre d'appli on se trouve)
- au niveau de l'ergonomie, l'apparence des pictos, etc... ça peut être 
mieux, mais c'est pas pire que ce que nous servent les appli autour 
d'OSM en général

- effectivement, OSMdata c'est mieux
- au moment du téléchargement, l'onglet de droite s'est mis à clignoter 
et je n'ai pas eu mon jeu de données
- est-ce qu'on aura une URL fixe pour chaque jeu de données qu'on s'est 
préparé à télécharger ? Comme ça on peut relancer le download tous les 
mois par exemple.


Merci.

Romain

Le 20/06/2020 à 12:53, Nelson Tayou a écrit :

Bonjour à tous,

Depuis l'AG du 13 juin 2020 nous avons informé du site 
geosm.openstreetmap.fr  qui est un 
visualiseur/téléchargeur  des données OSM.


Pour l'instant le nom de domaine est http://geosm.openstreetmap.fr 
 , mais il est pas adequat vu la 
ressemblance avec "JOSM".


Nous avons envisagé un nouveau nom plus simple qui pourrait être 
"OSMdata".


L'URL serait alors osmdata.openstreetmap.fr 
 Qu'en pensez-vous ?


Avant une communication plus large auprès du grand public et de nos 
partenaires, Vincent Bergeot a proposé de recueillir les suggestions 
et observations du plus grand nombre.


Tel est l'objet aussi de ce message. Notre idée est d'envisager la 
rentrée de septembre comme butée pour une mise en ligne "beta".


A vous lire, librement votre

_

geOSM

Aujourd'hui le nom de cette solution pourrait évoluer parce que ge0SM 
peut être confondu en l'écoutant avec JOSM qui est l'éditeur expert 
d'OpenStreetMap.


On pourrait envisager un nom plus facile à retenir qui serait osmdata 
et qui serait un clin d'oeil à OPENDATA ou encore en version plus 
longue OPENGEODATA.


 L'utilité d'un tel outil réside dans le fait d'avoir un démonstrateur 
et un visualiseur interactif des données OSM.


Un démonstrateur parce qu'il permet de montrer le niveau de maturité 
de la contribution à l'échelle de la France.


Visualiseur parce qu'il permet de manière conviviale de comprendre 
comment se répartissent les expertises des communautés de contributeurs.


L'outil version française permet de visualiser dans l'aire 
métropolitaine ainsi que dans les Dom et Tom.


A ce jour, l’interface admin mobilise 12 administrateurs ont été 
créés, plus de 330 couches sont mobilisables, regroupées sous 13 
géothématiques et valorise plus de 12 rendus cartographiques dérivés 
des données OSM ainsi que les orthophotos libres de droits.


Le code de ce projet est totalement open source est publié sur github 
.


Les sociétés 3LIZ et Makina Corpus et Géovéloont été sollicitées pour 
enrichir de leurs expertises l'interface avec en contrepartie 
l'opportunité d'y apposer des ressources et leur logo.


L'intérêt pour la communauté est d'avoir enfin une seule adresse à 
retenir permettant d'opérer des requêtes sur des contributions qui 
auront été faites (lors de cartoparties par exemple) ou encore de 
proposer à des organismes, collectivités locales une occasion simple 
de télécharger la donnée OSM simplement sur l'emprise géographique 
attendue.


Chaque couche sollicitée propose une option permettant de renvoyer sur 
des liens externes qui peuvent être des sites experts, des 
visualiseurs plus aboutis.


geOSM est mis à jour chaque semaine. Basé sur le serveur 
cartographique QGIS SERVER, il est donc compatible avec les feuilles 
de styles QML du logiciel QGIS DESKTOP.


L'intérêt de cette approche est de bénéficier de toute la force de 
frappe des développeurs de la communauté QGIS.


geOSM est aujourd'hui un sous domaine de l'association osm france et 
il sera hébergé par ses serveurs.


Annoncé initialement lors du SOTM-FR2019 à Montpellier, il a été 
soumis lors de l’assemblée générale OSM-FR en juin 2020.



___
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: [Talk-GB] Documenting tagging practice for place nodes in London

[Jez Nicholson]

I take it that these names are used by Nominatim to assist with search. I
know it's another form of tagging-for-the-renderer, but do you know
how/whether changes affect it?

On Tue, Jun 23, 2020 at 10:31 PM Russ Garrett  wrote:

> Hi folks,
>
> By way of lockdown procrastination, I started looking at place nodes
> in London. The main things which were annoying me are:
>
> * The presence of a few archaic place names which were presumably
> derived from NPE or other historic maps but are generally out of use
> now.
> * A surprisingly large number of place names present in OS StreetView
> are unmapped on OSM.
> * Most places in London are tagged as place=suburb, regardless of
> their size/importance. This issue especially is annoying me quite a
> lot now I've started noticing it.
>
> I started demoting some place=suburbs to place=quarter, and promoting
> one or two of them to place=town (as this seems to be almost
> universally used as the next level up from suburb in London), when it
> was pointed out that it's probably worth discussing this.
>
> These place tags are quite subjective, especially because they
> frequently get used for reasons which don't really tie in with their
> name, and wiki is pretty vague about their definition, so I don't
> think we can avoid some level of tagging for the renderer here.
>
> I think it would be useful to document which of these tags we want to
> use in London, and ideally some kind of heuristic for where to use
> them.
>
> I've generated a list of all place nodes within Greater London and the
> City, by type:
> https://wiki.openstreetmap.org/wiki/User:Ru/London_Place_Nodes
>
> Cheers,
>
> --
> Russ Garrett
> r...@garrett.co.uk
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] cadastre.openstreetmap.fr ???

[Marc M.]

Bonjour,

Le 23.06.20 à 11:37, Hélène PETIT a écrit :
> Après une migration mouvementée de win7 à debian10

félicitations :)

> c'est chouette ; ça résout mon problème immédiat

et pour fêter cela, la configuration a été corrigée
pour http://cadastre.openstreetmap.fr
(adaptation du fichier de config suite à la maj
d'il y a 2-3 jours. c'était passé inapercu).

Cordialement,
Marc

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

Re: [OSM-talk-fr] Bano v2

[Cyrille37 OSM]

Bonjour et merci,

Le 07/05/2020 à 10:59, Marc M. a écrit :

mais comme signalé, la veille base dont il dépend ne se met plus à jour
depuis le 11 avril, et donc les fichiers produits ne le sont pas.


C'est largement suffisant pour être très utile. Il manque tellement 
d'adresses qu'avec une couche BANO ancienne et le cadastre il y a déjà 
beaucoup de boulot faisable ;-)


et Merci encore !

Cyrille37.

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

Re: [Talk-de] "Driveway" als Fläche üblich/erlaubt?

[Florian Lohoff]

On Tue, Jun 23, 2020 at 07:18:37PM +0200, Manuel Reimer wrote:
> Hallo,
> 
> bei uns gibt es in der Nähe mehrere Ansammlungen von Garagen. Die Zufahrten
> dazu habe ich alle mit "highway=service" und "service=driveway" eingetragen.
> Allerdings entspricht das eigentlich nicht den örtlichen Gegebenheiten.
> Für's Routing wäre es nicht falsch (sofern es wirklich jemand nötig hat sich
> bis in seine Garage routen zu lassen) aber eigentlich ist die ganze Fläche
> vor und zwischen den Garagen-Reihen gepflastert. Man könnte einen beliebigen
> Weg über dieses Pflaster zur Garage nehmen.
> 
> Wäre es nun richtig, bzw. sinnvoll die Fläche *zusätzlich* zu den Wegen mit
> "area=yes" und den gleichen Tags wie für die Wege zu versehen um
> darzustellen das die ganze Fläche "driveway" ist?

Falsch ist das nicht. Für das Routing ändert das nichts. Sieht vielleicht
nur "hübscher" in der Karte aus. Ich mache sowas nicht weil ich immer
denke "je mehr Objekte des komplizierter das zu maintainen". Also trage
ich Zeugs ein was FÜR MICH Sinn ergibt.

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


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

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

[Florian LAINEZ]

Bonjour, c'est une bonne initiative, félicitations.
Je vous suggère de peaufiner le travail en passant par un graphiste. C'est
une étape qui me paraît importante : la forme d'un message compte autant
que le fond pour une communication efficace.
On l'a déjà fait par ailleurs : l'asso a financé le travail de graphiste
pour le dépliant :
https://wiki.openstreetmap.org/wiki/France/Support_Communication#D.C3.A9pliant_de_l.27asso_OSM-FR
Peut-être souhaiteriez-vous faire de même ?


Le mer. 24 juin 2020 à 07:45, Jean-Christophe Becquet  a
écrit :

> Le 22/06/2020 à 06:50, Jean-Christophe Becquet a écrit :
> > 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/
>
> Bonjour,
>
> Je viens dans mettre en ligne une nouvelle version du recto dans
> laquelle j'ai remplacé le texte :
>
> 16 ans d'existence
> 1 million de contributeurs actifs
> + de 30 éditions par seconde
>
> Par :
>
> Un  million  de  contributeurs  réalisent  plus de  30  éditions  par
> seconde  sur  la  base  de données mondiale depuis 16 ans.
> Rejoignez nous !
>
>
> Cela me semble plus dynamique et l'invitation à contribuer manquait.
>
> C'est là :
> http://linux-alpes.org/osm/flyer_osm_verso.pdf
>
> Bonne journée
>
> JCB
> --
> Des licences pour les logiciels libres
>
> http://www.apitux.org/index.php?2006/07/18/47-des-licences-pour-les-logiciels-libres
>
> ==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
>


-- 

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

Re: [talk-cz] [osm_sk] WeeklyOSM CZ 516

[Jakub Jelen]

On Tue, Jun 23, 2020 at 10:00 PM Jan Macura  wrote:
>
> On Tue, 23 Jun 2020 at 15:26, Jakub Jelen  wrote:
>>
>> Jenom drobna poznamka k prekladu. Myslim, ze "Výzkum chybějících
>> zastavěných oblastí v OpenStreetMap v Mozambiku" nebude mit nic
>> spolecneho s Twitterem, ale spise se bude jednat o nejaky specialni
>> typ shlukovani, podle rychleho pohledu na dokument.
>
>
> Ahoj,
>
> díky za připomínku. Tohle jsem překládal já, takže se klidně mohlo stát, že 
> jsem střelil úplně mimo. Článek samotný je sice schovaný za paywall, ale z 
> abstraktu bych naopak řekl, že s Twitterem souvisí.
> Shlukování aktivity uživatelů Twitteru nebo Facebooku používá aktivně třeba i 
> tým HOTu pro mapování Missing Maps – takové ty améby, co ohraničují mapované 
> území, pokud si je někdo vybaví z Tasking Manageru, mají někdy původ právě ve 
> shlukové analýze těchto dat.

Ahoj,
prave v nekterych nadpisech je to s malym T, coz me na tom trochu mate
(OpenStreetMap je s velkym).

Cely text je k dispozici zde:
https://www.researchgate.net/publication/341371133_Exploration_of_OpenStreetMap_Missing_Built-up_Areas_using_Twitter_Hierarchical_Clustering_and_Deep_Learning_in_Mozambique

A po proleteni to opravdu vypada, ze se jedna o pouziti dat z Twitteru.

Diky za vyvedeni z omylu :)

Jakub

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

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