Re: [Talk-it] [talk-it] cabina ascensore troppo piccola per bici normale

[Alessandro Sarretta]

Ciao Volker,

On 18/07/20 23:16, Volker Schmidt wrote:


Vista la tridimensionalità degli oggetti, credo sia meglio usare:
maxwidth=*, maxlenght=* e maxheight=*.

Il problema con questi è che sono tag che riguarda o l'accesso legale.
Nel caso ascensore l'unico disponibile sulla targhetta è maxweight, ma 
gli altri due non sono disponibili nel senso legale. Per questo posso 
solo mettere le dimensioni dell'oggetto, cioè width e length della cabina.


Per la larghezza massima non dal punto di vista legale ci sono due tag 
specifici documentati, maxheight:physical [0] e maxwidth:physical [1]; 
non sono molto usati, però mi sembra sarebbero quelli corretti da usare.


maxwidht:physical l'abbiamo usato estensivamente a Padova per mappare 
l'accessibilità dei marciapiedi in caso di ostacoli e restringimenti.


Ale


[0] https://wiki.openstreetmap.org/wiki/Key:maxheight:physical

[1] https://wiki.openstreetmap.org/wiki/Key:maxwidth:physical

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

Re: [OSM-talk-fr] Relation : multiples … ca existe ?

[Jérôme Amagat]

Le sam. 18 juil. 2020 à 11:31, Denis Chenu  a écrit :

> Merci, merci , merci …
>
> Donc : si de multiples éléments font parti d'un ensemble : j'ajoute un
> polygone avec son amenity.
> C'est bien cela le principe ?
>
> Si (au final) ce batiment : https://www.openstreetmap.org/way/79966828
> fait parti du Jardin, mais avec juste un chemin entre les 2.
> 1. Est ce que cela vaut la coup de l'ajouter
>

A toi de voir :)


> 2. Comment faire ?
>
> Ca depend si tout est d'un seul tenant avec le chemin qui fait aussi parti
du jardin, il faut agrandir le polygone pour englober le bâtiment et le
chemin. Si par contre le chemin ne fait pas parti du jardin et donc que ce
n'est pas d'un seul tenant alors il faut utiliser une relation
type=multipolygon, voir le wiki :
https://wiki.openstreetmap.org/wiki/FR:Relation:multipolygon#Deux_anneaux_ext.C3.A9rieurs_disjoints
il faut mettre les 2 polygones dans une relation avec comme rôle "outer"
pour les 2 polygones et les tag sur la relation et pas sur les polygones.
un exemple du même type : https://www.openstreetmap.org/relation/10837473


> Denis
> Le 18/07/2020 à 01:51, Jérôme Amagat a écrit :
>
> Tout ce trouve dans un polygone donc il ne faut pas une relation mais un
> polygone avec à l'intérieur les bâtiments, le jardin, le recycleur... et on
> sait que le composteur et les bâtiments font partie du "Jardin du Hêtre"
> parce qu'ils sont à l'intérieur, par contre il faut y mettre les bon tags
> dessus à part le nom. Je pense que c'est surtout un jardin donc le tag
> principal leisure=garden convient. J'ai modifié le polygone
> https://www.openstreetmap.org/way/787565928 et supprimé la relation.
>
> Le ven. 17 juil. 2020 à 15:25, Denis Chenu via Talk-fr <
> talk-fr@openstreetmap.org> a écrit :
>
>> Bonjour,
>>
>> J'ai une difficulté sur une relations, je ne sais pas comment la placer.
>> L'ensmble fait partie d'un seul élément "Jardin du Hétre"
>> La relation est la suivante
>> 1. Deux bâtiments coté rue
>> 2. 1 bâtiment intérieur (et plus)
>> 2. Une zone jardin (1 deuxième zone à construire)
>> 3. Un recycleur (compost partagé)
>>
>>
>> https://www.openstreetmap.org/?mlat=50.69923=3.16242#map=19/50.69923/3.16242
>> Pour l'instant : j'ai un multipolygone "Jardin du Hétre" en plus du
>> jardin "Jardin du Hétre" et du composteur "Jardin du Hétre" …
>>
>> On peut faire autrement ? Par exemple : indiquer quel est la partie du
>> batiment coté rue qui est l'entrée ?
>>
>> Merci
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-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] talk Digest, Vol 191, Issue 13

[Volker Schmidt]

o map assume these roads to be mapped properly. IMHO, adding
> > fixme=resurvey tracktype will not improve it. Data consumers usually do
> > not use tags like fixme=* In the case of imports (another type of mass
> > editing), we say that an import must not add fixme=* to cover
> > shortcomings of the data to be imported because they usually do not get
> > fixed in a reasonable time. Therefore, I plan to revert these changes.
> >
> > Modest7 does not seem to realise that estimating tracktype from
> > satellite imagery is not doing a service to OSM. I am currently
> > preparing a revert of all additions of surface=* and tracktype=* by him
> > he uploaded since 1 January 2020 [1]. The revert will only edit tags,
> > geometry will stay unchanged. I revert changes on surface as well
> > because that's not very different to tracktype except that it applies to
> > other types of roads as well.
> >
> > The countries which will be affected are:
> > Germany
> > Denmark
> > Turkey
> > United States
> > Poland
> > Ukraine
> > Morocco
> > Czech Republic
> > Lithuania
> > Sweden
> > Norway
> > eSwatini
> >
> > A changeset discussion with him can be found at
> > https://www.openstreetmap.org/changeset/87236896
> >
> > Best regards
> >
> > Michael
> >
> >
> > [1] This date is not fixed yet.
> >
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
> >
>
>
> --
> Florimond Berthoux
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstreetmap.org/pipermail/talk/attachments/20200718/0c3fc3d0/attachment-0001.htm
> >
>
> --
>
> Message: 5
> Date: Sat, 18 Jul 2020 19:29:50 +0200 (CEST)
> From: Mateusz Konieczny 
> To: Michael Reichert 
> Cc: "talk@openstreetmap.org" 
> Subject: Re: [OSM-talk] Planned revert of added surface and tracktype
> tags without local knowledge in various countries
> Message-ID: 
> Content-Type: text/plain; charset="utf-8"
>
> Can you link affected data in Poland?
>
> In Poland you actually can reliably estimate real tracktype based solely
> on high quality aerial images (not satellite imagery that is unlikely to
> be
> sufficient), typically Geoportal 2 aerial and LIDAR data available in ISOK
> Cień dataset.
>
> Note that your planned automatic revert likely counts as automatic
> edits and needs to fullfill
> https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
> requirements, including support from other editors.
>
> Jul 18, 2020, 12:53 by osm...@michreichert.de:
>
> > Hi,
> >
> > while reviewing changes in my local area, I discovered that user Modest7
> > has been adding tracktype=* tags to lots of highway=track at various
> > locations. I asked him what sources he used apart from the satellite
> > imagery mentioned in the imagery_used=* tag of his changesets. See
> > https://www.openstreetmap.org/changeset/87236896 for a discussion with
> him.
> >
> > I do not believe that one can add reliable tracktype=* information from
> > satellite imagery without having some ground truth knowledge in order to
> > know how to interpret the imagery in that region. Adding estimated
> > tracktype=* does not help OSM on the long term. People how rely on the
> > information (e.g. some wanting to drive or cycle on that track) are
> > disappointed about this low-quality OSM data. Mappers who decide where
> > to map assume these roads to be mapped properly. IMHO, adding
> > fixme=resurvey tracktype will not improve it. Data consumers usually do
> > not use tags like fixme=* In the case of imports (another type of mass
> > editing), we say that an import must not add fixme=* to cover
> > shortcomings of the data to be imported because they usually do not get
> > fixed in a reasonable time. Therefore, I plan to revert these changes.
> >
> > Modest7 does not seem to realise that estimating tracktype from
> > satellite imagery is not doing a service to OSM. I am currently
> > preparing a revert of all additions of surface=* and tracktype=* by him
> > he uploaded since 1 January 2020 [1]. The revert will only edit tags,
> > geometry will stay unchanged. I revert changes on surface as well
> > because that's not very different to tracktype except that it applies to
> > other types of roads as well.
> >
> > The countries which will be affected are:
> > Germa

Re: [OSM-talk] Planned revert of added surface and tracktype tags without local knowledge in various countries

[Mikel Maron]

A wide scale revert without assessing closely the quality and particulars in 
specific countries is not a good idea. Just an opinion that a method is flawed 
is not enough to demonstrate that such a wide scale revert is justified. Much 
more detailed analysis is needed before it should even be considered, and even 
then recommend that discussions should be opened up with local mapping 
communities in each place. It’s just not soemthing to do lightly.
Additionally, there may have been subsequent edits that would be lost in a 
revert.
I think if you look at your local area and determine that the mapping was not 
accurate in a large number of samples, you’d be justified reverting in that 
place. But you should still look carefully and make sure other good work is not 
undone in the process.

Mikel

On Saturday, July 18, 2020, 6:53 AM, Michael Reichert  
wrote:

Hi,

while reviewing changes in my local area, I discovered that user Modest7
has been adding tracktype=* tags to lots of highway=track at various
locations. I asked him what sources he used apart from the satellite
imagery mentioned in the imagery_used=* tag of his changesets. See
https://www.openstreetmap.org/changeset/87236896 for a discussion with him.

I do not believe that one can add reliable tracktype=* information from
satellite imagery without having some ground truth knowledge in order to
know how to interpret the imagery in that region. Adding estimated
tracktype=* does not help OSM on the long term. People how rely on the
information (e.g. some wanting to drive or cycle on that track) are
disappointed about this low-quality OSM data. Mappers who decide where
to map assume these roads to be mapped properly. IMHO, adding
fixme=resurvey tracktype will not improve it. Data consumers usually do
not use tags like fixme=* In the case of imports (another type of mass
editing), we say that an import must not add fixme=* to cover
shortcomings of the data to be imported because they usually do not get
fixed in a reasonable time. Therefore, I plan to revert these changes.

Modest7 does not seem to realise that estimating tracktype from
satellite imagery is not doing a service to OSM. I am currently
preparing a revert of all additions of surface=* and tracktype=* by him
he uploaded since 1 January 2020 [1]. The revert will only edit tags,
geometry will stay unchanged. I revert changes on surface as well
because that's not very different to tracktype except that it applies to
other types of roads as well.

The countries which will be affected are:
Germany
Denmark
Turkey
United States
Poland
Ukraine
Morocco
Czech Republic
Lithuania
Sweden
Norway
eSwatini

A changeset discussion with him can be found at
https://www.openstreetmap.org/changeset/87236896

Best regards

Michael


[1] This date is not fixed yet.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk



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

Re: [Talk-it] [talk-it] cabina ascensore troppo piccola per bici normale

[Volker Schmidt]

questione interessante per l'accessibilità in generale e non solo per le
> biciclette.
>
Mi sono reso conto subito, ma voleva porre un problema limitato :-)


> Vista la tridimensionalità degli oggetti, credo sia meglio usare:
> maxwidth=*, maxlenght=* e maxheight=*.
>
Il problema con questi è che sono tag che riguarda o l'accesso legale.
Nel caso ascensore l'unico disponibile sulla targhetta è maxweight, ma gli
altri due non sono disponibili nel senso legale. Per questo posso solo
mettere le dimensioni dell'oggetto, cioè width e length della cabina.

Una soluzione potrebbe essere di utilizzare

   - bicycle=yes per ascensori cui cabine sono chiaramente sufficientemente
   profondi per una bici normale appoggiata sulle due ruote.
   - bicycle=no se vietato esplicitamente o solo possibile in posizione
   verticale
   - bicycle=limited *più *le dimensioni width e length della cabina per
   casi intermedi (ispirato da wheelchair=limited)


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

Re: [OSM-talk] Planned revert of added surface and tracktype tags without local knowledge in various countries

[80hnhtv4agou--- via talk]

in the united states the hole thing starts out as gravel , 

  
>Saturday, July 18, 2020 3:44 PM -05:00 from Mike Thompson 
>:
> 
>   
>On Sat, Jul 18, 2020 at 2:23 PM Mark Wagner < mark+...@carnildo.com > wrote:
>  
>>* Two adjacent sections of track being tagged as "grade 2" and "grade
>>  4" not because of any difference in road surface, but because one has
>>  a line of grass between the ruts and the other doesn't.
>In rural areas where I have spent time people often only put gravel where the 
>wheels contract the ground, and leave the middle part of the road/track as is 
>(which is often grass/short native vegetation).  This is done to save money. 
>The result is that from overhead imagery, it may appear not to be gravel, and 
>thus may be incorrectly tagged at a lower tracktype.
>___
>talk mailing list
>talk@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk 
 
 
 
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Planned revert of added surface and tracktype tags without local knowledge in various countries

[Mike Thompson]

On Sat, Jul 18, 2020 at 2:23 PM Mark Wagner  wrote:

>
> * Two adjacent sections of track being tagged as "grade 2" and "grade
>   4" not because of any difference in road surface, but because one has
>   a line of grass between the ruts and the other doesn't.
>
In rural areas where I have spent time people often only put gravel where
the wheels contract the ground, and leave the middle part of the road/track
as is (which is often grass/short native vegetation).  This is done to save
money. The result is that from overhead imagery, it may appear not to be
gravel, and thus may be incorrectly tagged at a lower tracktype.

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

Re: [OSM-talk] Planned revert of added surface and tracktype tags without local knowledge in various countries

[Andy Townsend]

On 18/07/2020 20:51, Joseph Eisenberg wrote:
It's perfectly reasonable to add surface=unpaved or similar based on 
aerial imagery alone, if you have some experience in distinguishing 
different surfaces of roads and tracks from aerial imagery.


I'd agree that most of the time telling "surface=unpaved" from a paved 
road or track is certainly possible.  However, beyond that might be tricky.


As an example, here's one that I updated in OSM this morning. Have a 
look at https://www.openstreetmap.org/way/169902637 and follow that to 
the southwest.  The surface changes a few times before it meets the next 
road.  Do you believe that you would be able to infer those surface tags 
from imagery? I haven't added a tracktype there yet (lots of stuff in 
that area needs a resurvey!) and I'm sure you could say "it's definitely 
not tracktype=4 or 5" but I'd be reluctant to "overclaim" based on 
less-than-ideal sources.


Best Regards,

Andy




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

Re: [Talk-us] [Talk-us-newyork] Interested in importing address points in New York State

[Skyler Hawthorne]

On July 18, 2020 16:07:55 Russell Nelson  wrote:


Well there you go! You should make a page on the Wiki under Imports, and
save this email there. So it doesn't get lost. Like my NYSDEC email did. :(


I will make sure to do that when I get a chance!
--
Skyler



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

Re: [Talk-us] [Talk-us-newyork] Interested in importing address points in New York State

[Skyler Hawthorne]

On July 18, 2020 14:53:26 Mateusz Konieczny  wrote:



Not a lawyer, but is it possible that

"use the points for any lawful purpose"

is nonanswer as a use invaloving copyright infringement would not be lawful?


Also not a lawyer, but there is plenty of unambiguous context. I contacted 
him regarding the SAM Address Points in the NYS GIS Clearing House and he 
replied that he "would very much like the SAM address points to be included 
in Open Street Map." There's not much room for confusion or alternative 
interpretation.

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

Re: [OSM-talk] Planned revert of added surface and tracktype tags without local knowledge in various countries

[Mark Wagner]

Almost all of the tracktype mapping around me has been done by armchair
mappers working from from aerial images.

Tracks in my area are usually produced in one of two ways:

* A bulldozer is used to scrape vegetation and topsoil off.
* A given route is driven repeatedly, eroding any vegetation or
  topsoil.

Either way, the track surface is composed of whatever's underneath the
top layer.  If I understand tracktype tagging correctly, this should be
grade 4 or 5, depending on how much gravel and/or clay is present in
the soil.  Actual tagging is almost uniformly divided between grades 2,
3, 4, and 5, with a few spots of grade 1.

Some of the more interesting inconsistencies:

* A road being "grade 2" north of an intersection and "grade 3" south
  of it, despite being the same dirt surface on both sides.
* An abandoned railroad being a mix of "grade 3" and "grade 4", despite
  the track ballast (grade 2) still being present and visible in aerial
  imagery.
* Two adjacent sections of track being tagged as "grade 2" and "grade
  4" not because of any difference in road surface, but because one has
  a line of grass between the ruts and the other doesn't.

-- 
Mark

On Sat, 18 Jul 2020 18:51:57 +0200
Florimond Berthoux  wrote:

> I see no big issue of using only aerial images to set track_type or
> surface. You can get a fairly good result with such sources.
> So no, you should not blindly revert its modifications.
> If the estimation was really bad almost all the time why not, but
> here the example given is ok.
> 
> Le sam. 18 juil. 2020 à 12:56, Michael Reichert
>  a écrit :
> 
> > Hi,
> >
> > while reviewing changes in my local area, I discovered that user
> > Modest7 has been adding tracktype=* tags to lots of highway=track
> > at various locations. I asked him what sources he used apart from
> > the satellite imagery mentioned in the imagery_used=* tag of his
> > changesets. See https://www.openstreetmap.org/changeset/87236896
> > for a discussion with him.
> >
> > I do not believe that one can add reliable tracktype=* information
> > from satellite imagery without having some ground truth knowledge
> > in order to know how to interpret the imagery in that region.
> > Adding estimated tracktype=* does not help OSM on the long term.
> > People how rely on the information (e.g. some wanting to drive or
> > cycle on that track) are disappointed about this low-quality OSM
> > data. Mappers who decide where to map assume these roads to be
> > mapped properly. IMHO, adding fixme=resurvey tracktype will not
> > improve it. Data consumers usually do not use tags like fixme=* In
> > the case of imports (another type of mass editing), we say that an
> > import must not add fixme=* to cover shortcomings of the data to be
> > imported because they usually do not get fixed in a reasonable
> > time. Therefore, I plan to revert these changes.
> >
> > Modest7 does not seem to realise that estimating tracktype from
> > satellite imagery is not doing a service to OSM. I am currently
> > preparing a revert of all additions of surface=* and tracktype=* by
> > him he uploaded since 1 January 2020 [1]. The revert will only edit
> > tags, geometry will stay unchanged. I revert changes on surface as
> > well because that's not very different to tracktype except that it
> > applies to other types of roads as well.
> >
> > The countries which will be affected are:
> > Germany
> > Denmark
> > Turkey
> > United States
> > Poland
> > Ukraine
> > Morocco
> > Czech Republic
> > Lithuania
> > Sweden
> > Norway
> > eSwatini
> >
> > A changeset discussion with him can be found at
> > https://www.openstreetmap.org/changeset/87236896
> >
> > Best regards
> >
> > Michael
> >
> >
> > [1] This date is not fixed yet.
> >
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
> >  
> 
> 


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

Re: [Talk-us] [Talk-us-newyork] Interested in importing address points in New York State

[Russell Nelson]

Well there you go! You should make a page on the Wiki under Imports, and 
save this email there. So it doesn't get lost. Like my NYSDEC email did. :(


On 7/18/20 12:34 PM, Skyler Hawthorne wrote:
Well, it turned it to be a lot easier than I was thinking it would be! 
I reached out to the contact listed on the Clearing House web site, 
using the template in the wiki page, and he replied confirming that we 
have permission to use the data. This is the text of the email 
exchange, and I've also attached the raw .eml file. 


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

Re: [OSM-talk-fr] MapContrib en Allemand pour le projet Karto-District

[DH]

Le 18/07/2020 à 10:06, Vincent Bergeot a écrit :


Bonjour,

...

Au passage ce projet a permis la tenue d'une table ronde sur la 
cartographie transfrontalière filmée (Frédérick Ramm, Kristine Karch 
et moi même étions les "experts" OSM, merci à DenisH pour les mises en 
lien). Cette vidéo devrait être visible dans un moment, lorsque le 
montage avec les traductions sera finalisé. En attendant vous pouvez 
aller voir cette vidéo de présentation d'OSM : 
https://kartodistrict.eu/index.php/ExpertVideos#OpenStreetMap).


Bonne journée



Merci Vincent pour ces bonnes nouvelles.

Cela me rappelle que je dois encore au projet Karto-district une 
présentation d'OSM côté contributeur. J'oublie pas mais je suis noyé 
pour le moment mais les vacances approchent...


Des dates/mode-op  pour la cartopartie prévue ?

Denis



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

Re: [OSM-talk] Planned revert of added surface and tracktype tags without local knowledge in various countries

[Joseph Eisenberg]

It's perfectly reasonable to add surface=unpaved or similar based on aerial
imagery alone, if you have some experience in distinguishing different
surfaces of roads and tracks from aerial imagery.

Do you have evidence that most of the surface tags added by this user are
unreliable?

– Joseph Eisenberg

On Sat, Jul 18, 2020 at 12:34 PM Michael Reichert 
wrote:

> Hi,
>
> Am 18/07/2020 um 21.19 schrieb Mateusz Konieczny via talk:
> > Are you sure that just satellite imagery was used? I suspect that also
> > aerial imagery was used in edits.
>
> In Hamburg, Germany, where aerial imagery of the city is available, Bing
> was used.
>
> >> I think that the description "all objects modified by Modest7 since 1
> >> January 2020" is sufficient.
> >>
> > I thought that revert was supposed to cover tracktype edits only?
>
> That was my plan initially. However, after scrolling back his edit
> history, I found edits adding surface in the US. There is some overlap
> in the meaning of surface and tracktype, therefore I think that it makes
> more sense revert changes to both tracktype and surface, not tracktype
> only. The revert is limited to these two tags because some changes by
> Modest7 are indeed helpful, e.g. adding intersection nodes to
> intersecting roads.
>
> Best regards
>
> Michael
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Planned revert of added surface and tracktype tags without local knowledge in various countries

[Michael Reichert]

Hi,

Am 18/07/2020 um 21.19 schrieb Mateusz Konieczny via talk:
> Are you sure that just satellite imagery was used? I suspect that also
> aerial imagery was used in edits.

In Hamburg, Germany, where aerial imagery of the city is available, Bing
was used.

>> I think that the description "all objects modified by Modest7 since 1
>> January 2020" is sufficient.
>>
> I thought that revert was supposed to cover tracktype edits only?

That was my plan initially. However, after scrolling back his edit
history, I found edits adding surface in the US. There is some overlap
in the meaning of surface and tracktype, therefore I think that it makes
more sense revert changes to both tracktype and surface, not tracktype
only. The revert is limited to these two tags because some changes by
Modest7 are indeed helpful, e.g. adding intersection nodes to
intersecting roads.

Best regards

Michael



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

Re: [OSM-talk] Planned revert of added surface and tracktype tags without local knowledge in various countries

[Mateusz Konieczny via talk]

Jul 18, 2020, 21:09 by osm...@michreichert.de:

> Hi Mateusz,
>
> Am 18/07/2020 um 19.29 schrieb Mateusz Konieczny:
>
>> Can you link affected data in Poland? 
>>
>> In Poland you actually can reliably estimate real tracktype based solely
>> on high quality aerial images (not satellite imagery that is unlikely to be 
>> sufficient), typically Geoportal 2 aerial and LIDAR data available in ISOK 
>> Cień dataset.
>>
>> Note that your planned automatic revert likely counts as automatic 
>> edits and needs to fullfill
>> https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
>> requirements, including support from other editors.
>>
>
> I do not think that my revert is an automated edit as intended by the
> Automated Edits Code of Conduct.I am reaching out to the community in
> advance because different people might have a different opinion on how
> reliable tracktype=* needs to be and how reliable surveying from
> satellite imagery is.
>
Are you sure that just satellite imagery was used? I suspect that also
aerial imagery was used in edits.

>
> I think that the description "all objects modified by Modest7 since 1
> January 2020" is sufficient.
>
I thought that revert was supposed to cover tracktype edits only?

> You can use OSMcha, can't you?
>
I am unfamiliar with OSMcha.

>  Or would you
> like to have a large .osc files of his changes?
>
I would prefer list of OSM objects that would be affected within boundaries
of Poland.

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

Re: [OSM-talk] Planned revert of added surface and tracktype tags without local knowledge in various countries

[Michael Reichert]

Hi Mateusz,

Am 18/07/2020 um 19.29 schrieb Mateusz Konieczny:
> Can you link affected data in Poland? 
> 
> In Poland you actually can reliably estimate real tracktype based solely
> on high quality aerial images (not satellite imagery that is unlikely to be 
> sufficient), typically Geoportal 2 aerial and LIDAR data available in ISOK 
> Cień dataset.
> 
> Note that your planned automatic revert likely counts as automatic 
> edits and needs to fullfill
> https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
> requirements, including support from other editors.

I do not think that my revert is an automated edit as intended by the
Automated Edits Code of Conduct. I am reaching out to the community in
advance because different people might have a different opinion on how
reliable tracktype=* needs to be and how reliable surveying from
satellite imagery is.

I think that the description "all objects modified by Modest7 since 1
January 2020" is sufficient. You can use OSMcha, can't you? Or would you
like to have a large .osc files of his changes?

Currently, the revert is disputed. That's not a condition I would like
to have for a mass edit. If people in favour of a revert will not voice
their opinion in this discussion, it is very likely that I will not do
the revert on international level.

The Polish community is free to object as it is their data (quality),
not mine. I asked the German community today because I suspect that
Germans are quite sensible when it comes to one of our key assets of OSM
in Germany: surveyed highway=track. If people on the German forum agree
with a revert, the revert will be limited to Germany. If other local
communities ask me to perform the revert in their country, I will do it
there.
https://forum.openstreetmap.org/viewtopic.php?id=70056

Best regards

Michael



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

Re: [Talk-transit] Bus routes in Málaga: Should we add "stop_area" relations?

[80hnhtv4agou--- via Talk-transit]

the Tag:railway=stop, has some of the same issues.

  
>Saturday, July 18, 2020 12:27 PM -05:00 from Jarek Piórkowski 
>:
> 
>On Sat, 18 Jul 2020 at 13:17, Daniel Capilla < dcapil...@gmail.com > wrote:
>> When we started mapping the bus routes in Málaga, Alan Grant and I came
>> to the conclusion that it was not necessary to add "stop_area" relations
>> due to the type of bus stops in Málaga, [2] where there are no actual
>> stop areas (only a stop position in the own road and a pole on the
>> sidewalk usually).
>>
>> Is that solution correct? Should we add "stop_area" relations at every
>> bus stop position? I would have to create a lot of additional relations,
>> only with the stop position and the platform features. I am not sure if
>> that would be reasonable/useful for any purpose. What do you think?
>>
>> [2]
>>  
>> https://wiki.openstreetmap.org/wiki/ES_talk:Rutas_de_bus_en_M%C3%A1laga#Uso_de_la_relaci.C3.B3n_.22stop_area.22
>> (in Spanish)
>stop_area does not seem necessary for support in many popular OSM
>transit data consumers (OsmAnd and öpnvkarte/openbusmap come to mind).
>You probably don't have to add them unless something is really unclear
>without it. In particular it doesn't seem very necessary for simple
>cases like 2 stops on either side of the road. (It won't hurt, but
>it's not necessary.)
>
>Reading through (autotranslated) wiki discussion, it does make some
>sense that stop_area is more useful in areas where a number of
>physical halt points share one ref ID. If that's not the case for you,
>probably don't need to bother.
>
>--Jarek
>
>___
>Talk-transit mailing list
>Talk-transit@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-transit 
 
 
 
 ___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-us] [Talk-us-newyork] Interested in importing address points in New York State

[Mateusz Konieczny via Talk-us]

Not a lawyer, but is it possible that
"use the points for any lawful purpose"
is nonanswer as a use invaloving copyright infringement would not be lawful?

Jul 18, 2020, 18:34 by o...@dead10ck.com:

> Well, it turned it to be a lot easier than I was thinking it would be! I 
> reached out to the contact listed on the Clearing House web site, using the 
> template in the wiki page, and he replied confirming that we have permission 
> to use the data. This is the text of the email exchange, and I've also 
> attached the raw .eml file.
>
> From: Winters, Frank (ITS) frank.wint...@its.ny.gov
> Date: July 17, 2020 22:30:24
> Subject: RE: Interested in importing the Address Point data from the Clearing 
> House into OpenStreetMap
> To: Skyler Hawthorne o...@dead10ck.com
> CC: Coryell, Rodger (ITS) rodger.cory...@its.ny.gov, Fargione, Craig (ITS) 
> craig.fargi...@its.ny.gov
>
> Hi Skyler, nice to hear form you. We would very much like the SAM address 
> points to be included in Open Street Map. The permitted use of the points is 
> quite simple. You may use the points for any lawful purpose. While we do our 
> best to maintain a comprehensive and accurate set of address points with our 
> limited resources we know it has shortcomings. See the metadata for the 
> liability disclaimer.
>
> We generally post quarterly updates to the data set.
>
>
> Frank Winters
> Geographic Information Officer
>
> Office of Information Technology Services
> W. Averell Harriman State Office Campus
> Bldg. 5 - Floor 1
> Albany, NY 12226
> 518.242.5036 | 518.281.9140 m | frank.wint...@its.ny.gov
>
>
> -Original Message-
> From: Skyler Hawthorne  Sent: Friday, July 17, 2020 6:30 PM
> To: Winters, Frank (ITS) 
> Subject: Interested in importing the Address Point data from the Clearing 
> House into OpenStreetMap
>
> ATTENTION: This email came from an external source. Do not open attachments 
> or click on links from unknown senders or unexpected emails.
>
> Hello Mr Winters,
>
> Thank you for your part in making the GIS data for New York State available 
> to the public through the Clearing House project!
>
> I am a contributor to the OpenStreetMap project [1], a collaborative open 
> project to create a global geodata set freely usable by anyone [2].
>
> We respect the IP rights of others and I write to ask if we can use this 
> data. There does not appear to be any explicit information about the license 
> under which the data sets in the Cleaning House web site are distributed. 
> It's unclear what the terms are for its use, and specifically whether or not 
> it is public domain, and if it is permitted to import into the OpenStreetMap 
> project and redistribute to the world under an open license.
>
> At the most simple, I would seek a statement like this:
>
> "The New York State GIS Program Office [or the relevant NYS department(s)] 
> has no objections to geodata derived in part from the GIS Clearing House data 
> sets being incorporated into the OpenStreetMap project geodata database and 
> released under a free and open license" [1]
>
> I also ask that whatever statement you are prepared to make can be made 
> public for information purposes.
>
> Below is a fact sheet. If you would like any more information, I will do my 
> best to help or can ask our project's License Working Group to get in touch 
> with you.
>
> Regards,
> Skyler Hawthorne
>
> Fact Sheet
>
> [1] The OpenStreetMap project currently has over 750,000 registered 
> contributors worldwide. Our main website is https://www.openstreetmap.org
>
> [2] We are mandated to make our geodata available in perpetuity under a free 
> and open licence. We are not allowed to use a commercial license, but 
> commercial organisations are allowed to use our data under similar terms.
>
> [3] Our data is currently published under the Open Database License 1.0, 
> https://protect2.fireeye.com/v1/url?k=76761582-2a4eb33f-7674ecb7-000babd9fa3f-f71edf933744da0d=1=391ef603-5912-439f-b6e4-b8ac749598bd=http%3A%2F%2Fwww.opendatacommons.org%2Flicenses%2Fodbl%2F
>
> [4] Most of our geodata is contributed by individuals. However, we are very 
> grateful when able to incorporate or derive from other geo-data datasets 
> where license terms are compatible.
>
> [5] We formally attribute all such sources at 
> https://wiki.openstreetmap.org/wiki/Attribution, using any specific wording 
> if you request. We also try to provide a link to this page with any extract 
> of data from our database. However, for reasons of practicality, we do not 
> require end-users to repeat such attribution since it runs into hundreds.
>
> [6] We also keep a public track of third party data use at 
> https://wiki.openstreetmap.org/wiki/Import/Catalogue and usually have a 
> project page for each dataset, describing how we use it and whether there are 
> any license restrictions to be aware of.
>
> [7] If you have any specific legal questions, the OpenStreetMap Foundation's 
> License Working Group can be reached 

Re: [OSM-talk] Planned revert of added surface and tracktype tags without local knowledge in various countries

[Mateusz Konieczny via talk]

Jul 18, 2020, 20:07 by osm...@michreichert.de:

> Am 18/07/2020 um 19.29 schrieb Mateusz Konieczny:
>
>> Can you link affected data in Poland? 
>>
>> In Poland you actually can reliably estimate real tracktype based solely
>> on high quality aerial images (not satellite imagery that is unlikely to be 
>> sufficient), typically Geoportal 2 aerial and LIDAR data available in ISOK 
>> Cień dataset.
>>
>
> I don't have a list of the affected OSM objects at hand but you can
> filter his changesets in Poland using OSMCha. Note that I do not
> guarantee that Poland is affected at all. It might be that his changes
> in Poland are limited to other kinds of contributions like adding nodes
> to intersecting roads.
>
In case of anyone planning such automatic revert next step should include
full list of OSM objects that will be affected, to allow checking of what is 
actually planned.

Without such overwiew I oppose such edit and I strongly oppose doing such 
automatic edit in Poland.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-transit] Bus routes in Málaga: Should we add "stop_area" relations?

[Jo]

Hi Daniel,

If you would like to participate in a Hangout, I can explain to you how
PT_Assistant can help you with this task.

We can even do that in Spanish, si te gusta.

Personally, I would also only map highway=bus_stop (with or without
public_transport=platform) on nodes next to the highway, so no real need
for stop_area relations.

Polyglot

On Sat, Jul 18, 2020 at 7:36 PM Mateusz Konieczny via Talk-transit <
talk-transit@openstreetmap.org> wrote:

>
>
>
> Jul 18, 2020, 19:17 by dcapil...@gmail.com:
>
> Hi!
>
> I'll try to check the bus routes in Malagá. [1] I haven't checked them for
> a long time because I have been busy with other mapping tasks and because
> there were many changes in the central area of Málaga. The bus routes
> changed too often. Now it seems to be stabilizing, there are less and less
> changes, and I thought it would be a good time to check the mapping. I'd
> like to ask you something first.
>
> When we started mapping the bus routes in Málaga, Alan Grant and I came to
> the conclusion that it was not necessary to add "stop_area" relations due
> to the type of bus stops in Málaga, [2] where there are no actual stop
> areas (only a stop position in the own road and a pole on the sidewalk
> usually).
>
> Is that solution correct? Should we add "stop_area" relations at every bus
> stop position? I would have to create a lot of additional relations, only
> with the stop position and the platform features. I am not sure if that
> would be reasonable/useful for any purpose. What do you think?
>
> highway=bus_stop node is typically sole useful and needed part of mapping
> bus stop
>
> (additional tags on this node, starting from name are obviously useful)
>
> stop_position, stop_areas and so on are generally not useful, except
> extremely rare cases
>
> I would rather map bus routes than and do other OSM mapping over pointless
> duplicating
> of information available thanks to highway=bus_stop
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [OSM-talk] Planned revert of added surface and tracktype tags without local knowledge in various countries

[Andy Townsend]

On 18/07/2020 17:51, Florimond Berthoux wrote:


If the estimation was really bad almost all the time why not, but here 
the example given is ok.



How do you know - have you visited that area and done a ground survey?

Best Regards,

Andy



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

[Talk-GB] TPT / NCN62 (was: Re: National Cycle Network removal/reclassification)

[Andy Townsend]

On 18/07/2020 17:06, Adam Snape wrote:
On the subject of overlapping relations. I've recently noticed that 
the NCN 62 relation has been named Transpennine trail which is true 
for much, but not all of the route. The TPT ends at Southport, yet NCN 
62 continues further North. At the eastern end of the TPT goes far 
beyond the end of NCN 62 which ends at Selby. They need to be two 
separate relations.


The Trans-Pennine Trail is a bit confusing, both on the ground and in 
OSM.  A quick query in OSM south of Selby turns up this:


https://www.openstreetmap.org/relation/12763

"ref=62; name=Trans Pennine Trail"

and this:

https://www.openstreetmap.org/relation/1761919#map=10/53.7874/-0.6265=H

"ref=TPT; name=Trans Pennine Trail"

and also this:

https://www.openstreetmap.org/relation/10521621#map=10/53.6371/-1.2158=H

"name=Trans Pennine Trail (Wombwell to Selby)"

It essentially goes all over the place, and doesn't correspond to one 
particular NCN (see 
https://www.transpenninetrail.org.uk/?doing_wp_cron=1595095458.735897064208984375 
).  The Chesterfield end has two braids and partially corresponds to 
what is or was NCN 67.


The superroute I believe is https://www.openstreetmap.org/relation/4139041

If NCN 62 isn't properly called the Transpennine Trail I'd remove that 
name from it and explain in a note on the relation why.  My recollection 
is that NCN62 and TPT signage is separate, but it's a while since I've 
seen any so I may be wrong.


The best approach for tidying would I think be to:

 * Find anything not in the superroute and figure out what the status
   actually is.
 * Ensure that routes in the superroute are split where tags change
   (e.g. bits with NCN 62 signage and bits without)

It'd be a lot of work for relatively little reward though - presumably 
that's why no-one's stepped up to tidy things up yet.


Best Regards,

Andy



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

Re: [OSM-talk] Planned revert of added surface and tracktype tags without local knowledge in various countries

[Michael Reichert]

Hi Mateusz,

Am 18/07/2020 um 19.29 schrieb Mateusz Konieczny:
> Can you link affected data in Poland? 
> 
> In Poland you actually can reliably estimate real tracktype based solely
> on high quality aerial images (not satellite imagery that is unlikely to be 
> sufficient), typically Geoportal 2 aerial and LIDAR data available in ISOK 
> Cień dataset.

I don't have a list of the affected OSM objects at hand but you can
filter his changesets in Poland using OSMCha. Note that I do not
guarantee that Poland is affected at all. It might be that his changes
in Poland are limited to other kinds of contributions like adding nodes
to intersecting roads.

Best regards

Michael



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

Re: [Talk-lt] Vilnius ketina paskelbti ženklų žemėlapį

[Tomas Straupis]

Laba diena

2020-07-17, pn, 18:20 Eduardas Kriščiūnas rašė:
> Rašo, kad bus kaip Klaipėdoje. Tomai, ar esi matęs jį? Gal reikia kaip
> nors kitaip duomenis pateikti, kad ir OSM naudos būtų?

  Kaip suprantu, būtų galima pažiūrėti, pakoreguoti eismo ribojimus,
vienpusius eismus, gal net juostas. Tikriausiai bet kokiu atveju būtų
rankinis darbas, tai tada turėtų tikti ir Klaipėdos variantas.

-- 
Tomas

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

Re: [OSM-talk] Planned revert of added surface and tracktype tags without local knowledge in various countries

[stevea]

I modestly (on occasion) set tracktype=* based on imagery, but only using 
higher-quality imagery where I have high confidence I can quite accurately do 
so.  On those few occasions where I later visit the site / track and am able to 
glean how accurate my tagging was, I've either never had to change it to a 
different value or it was such a long time between setting and visiting that it 
was one value different (higher based on increased use, lower based on 
decreased use and falling into reverting to the landscape).  So, done with 
skill, this sort of armchair mapping can be and is done accurately quite 
frequently, in my experience of both doing this and observing others doing this 
(and reading the confirmation of that here and now).

That is me, your mileage may vary, though as others have said similar (that 
they do this), I, too, would refrain from performing a revert.  If, on the 
other hand, you are certain that _individual_ tracks are clearly wrong, I'd say 
go ahead and change those one-at-a-time, but a wholesale revert, no, that seems 
like overkill.

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

Re: [Talk-transit] Bus routes in Málaga: Should we add "stop_area" relations?

[Mateusz Konieczny via Talk-transit]

Jul 18, 2020, 19:17 by dcapil...@gmail.com:

> Hi!
>
> I'll try to check the bus routes in Malagá. [1] I haven't checked them for a 
> long time because I have been busy with other mapping tasks and because there 
> were many changes in the central area of Málaga. The bus routes changed too 
> often. Now it seems to be stabilizing, there are less and less changes, and I 
> thought it would be a good time to check the mapping. I'd like to ask you 
> something first.
>
> When we started mapping the bus routes in Málaga, Alan Grant and I came to 
> the conclusion that it was not necessary to add "stop_area" relations due to 
> the type of bus stops in Málaga, [2] where there are no actual stop areas 
> (only a stop position in the own road and a pole on the sidewalk usually).
>
> Is that solution correct? Should we add "stop_area" relations at every bus 
> stop position? I would have to create a lot of additional relations, only 
> with the stop position and the platform features. I am not sure if that would 
> be reasonable/useful for any purpose. What do you think?
>
highway=bus_stop node is typically sole useful and needed part of mapping bus 
stop

(additional tags on this node, starting from name are obviously useful)

stop_position, stop_areas and so on are generally not useful, except extremely 
rare cases

I would rather map bus routes than and do other OSM mapping over pointless 
duplicating
of information available thanks to highway=bus_stop
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [OSM-talk] Planned revert of added surface and tracktype tags without local knowledge in various countries

[Mateusz Konieczny via talk]

Can you link affected data in Poland? 

In Poland you actually can reliably estimate real tracktype based solely
on high quality aerial images (not satellite imagery that is unlikely to be 
sufficient), typically Geoportal 2 aerial and LIDAR data available in ISOK Cień 
dataset.

Note that your planned automatic revert likely counts as automatic 
edits and needs to fullfill
https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
requirements, including support from other editors.

Jul 18, 2020, 12:53 by osm...@michreichert.de:

> Hi,
>
> while reviewing changes in my local area, I discovered that user Modest7
> has been adding tracktype=* tags to lots of highway=track at various
> locations. I asked him what sources he used apart from the satellite
> imagery mentioned in the imagery_used=* tag of his changesets. See
> https://www.openstreetmap.org/changeset/87236896 for a discussion with him.
>
> I do not believe that one can add reliable tracktype=* information from
> satellite imagery without having some ground truth knowledge in order to
> know how to interpret the imagery in that region. Adding estimated
> tracktype=* does not help OSM on the long term. People how rely on the
> information (e.g. some wanting to drive or cycle on that track) are
> disappointed about this low-quality OSM data. Mappers who decide where
> to map assume these roads to be mapped properly. IMHO, adding
> fixme=resurvey tracktype will not improve it. Data consumers usually do
> not use tags like fixme=* In the case of imports (another type of mass
> editing), we say that an import must not add fixme=* to cover
> shortcomings of the data to be imported because they usually do not get
> fixed in a reasonable time. Therefore, I plan to revert these changes.
>
> Modest7 does not seem to realise that estimating tracktype from
> satellite imagery is not doing a service to OSM. I am currently
> preparing a revert of all additions of surface=* and tracktype=* by him
> he uploaded since 1 January 2020 [1]. The revert will only edit tags,
> geometry will stay unchanged. I revert changes on surface as well
> because that's not very different to tracktype except that it applies to
> other types of roads as well.
>
> The countries which will be affected are:
> Germany
> Denmark
> Turkey
> United States
> Poland
> Ukraine
> Morocco
> Czech Republic
> Lithuania
> Sweden
> Norway
> eSwatini
>
> A changeset discussion with him can be found at
> https://www.openstreetmap.org/changeset/87236896
>
> Best regards
>
> Michael
>
>
> [1] This date is not fixed yet.
>

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

Re: [Talk-transit] Bus routes in Málaga: Should we add "stop_area" relations?

[Jarek Piórkowski]

On Sat, 18 Jul 2020 at 13:17, Daniel Capilla  wrote:
> When we started mapping the bus routes in Málaga, Alan Grant and I came
> to the conclusion that it was not necessary to add "stop_area" relations
> due to the type of bus stops in Málaga, [2] where there are no actual
> stop areas (only a stop position in the own road and a pole on the
> sidewalk usually).
>
> Is that solution correct? Should we add "stop_area" relations at every
> bus stop position? I would have to create a lot of additional relations,
> only with the stop position and the platform features. I am not sure if
> that would be reasonable/useful for any purpose. What do you think?
>
> [2]
> https://wiki.openstreetmap.org/wiki/ES_talk:Rutas_de_bus_en_M%C3%A1laga#Uso_de_la_relaci.C3.B3n_.22stop_area.22
> (in Spanish)

stop_area does not seem necessary for support in many popular OSM
transit data consumers (OsmAnd and öpnvkarte/openbusmap come to mind).
You probably don't have to add them unless something is really unclear
without it. In particular it doesn't seem very necessary for simple
cases like 2 stops on either side of the road. (It won't hurt, but
it's not necessary.)

Reading through (autotranslated) wiki discussion, it does make some
sense that stop_area is more useful in areas where a number of
physical halt points share one ref ID. If that's not the case for you,
probably don't need to bother.

--Jarek

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

[Talk-transit] Bus routes in Málaga: Should we add "stop_area" relations?

[Daniel Capilla]

Hi!

I'll try to check the bus routes in Malagá. [1] I haven't checked them 
for a long time because I have been busy with other mapping tasks and 
because there were many changes in the central area of Málaga. The bus 
routes changed too often. Now it seems to be stabilizing, there are less 
and less changes, and I thought it would be a good time to check the 
mapping. I'd like to ask you something first.


When we started mapping the bus routes in Málaga, Alan Grant and I came 
to the conclusion that it was not necessary to add "stop_area" relations 
due to the type of bus stops in Málaga, [2] where there are no actual 
stop areas (only a stop position in the own road and a pole on the 
sidewalk usually).


Is that solution correct? Should we add "stop_area" relations at every 
bus stop position? I would have to create a lot of additional relations, 
only with the stop position and the platform features. I am not sure if 
that would be reasonable/useful for any purpose. What do you think?


Thank you!

Regards,

Daniel


[1] https://wiki.openstreetmap.org/wiki/Bus_routes_in_M%C3%A1laga

[2] 
https://wiki.openstreetmap.org/wiki/ES_talk:Rutas_de_bus_en_M%C3%A1laga#Uso_de_la_relaci.C3.B3n_.22stop_area.22 
(in Spanish)



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

Re: [OSM-talk-fr] ref et ref:FR

[leni]

Bonjour.

Le sam. 15 févr. 2020 à 18:02, Philippe Verdy > a écrit :


J'ai continue à renseigner des colonnes dans ta feuille
https://lite.framacalc.org/9f0b-osm_ref_fr

Je pense avoir laissé assez de temps pour que tout un chacun ait pu le 
compléter, je vais la reporter dans le wiki




Noter que certaines références sont problématiques, de droit privé
et pas forcément libres. Certaines sont très peu utilisées voire
pas du tout.

Je vais les enlever du tableau principal et les mettre dans un tableau 
annexe :
ref:FR:BigBus, ref:FR:BPALC, ref:FR:gites-de-france, ref:FR:Open_Tour, 
ref:FR:RelaisColis




Les cellules à problème sont soulignées en orange.

Je vais aussi mettre la colonne remarque et récapituler en dessous les 
remarques





Mais il manque certainement des tas d'autres "ref**" à ce tableau.


> J'en ai certainement loupé ...

Comme je l'avais dit dans mon message initial. En fait, je n'ai cherché 
que les ref:FR que sur les nodes, pour les ways ou les relations, 
j'étais obligé de limiter ma recherche au niveau du département, et 
comme je ne voulais pas y passer mes nuits ...





Le 11/02/2020 à 23:47, François Lacombe a écrit :
> +1 avec vous, bonne idée de séparer le tableau, pourquoi pas
par
> thèmes, comme nous le faisons pour les Map Features ?

En fait je ne vais pas le séparer, car le tableau est copié par macro 
sur la page https://wiki.openstreetmap.org/wiki/FR:Key:ref et je ne sais 
pas l'utiliser, j'ai donc ajouté une colonne thème, mais pas beaucoup 
d'idées, voici ceux qui ont été saisis, beaucoup restent sans thème ...
_Liste des thèmes_ présents : administratif, adresses, amenity, 
associations, culture, économie, éducation, énergie, entreprise, 
environnement, handicap, hydrographie, naturel, religion, sécurité, 
telecom, tourisme, transport




- ceux qui n'ont pas de FR: (8)
- ceux qui sont avec fr_ (2)
- ceux qui sont en FR: (38)

Je pense les laisser dans le tableau principal (car il est dupliqué par 
macro sur l'autre page)




- ceux qui sont dans osm et qui ne sont pas dans le wiki


Je les enlèverais pour les mettre dans un tableau à la suite de l'autre


leni

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

Re: [OSM-talk] Planned revert of added surface and tracktype tags without local knowledge in various countries

[Florimond Berthoux]

I see no big issue of using only aerial images to set track_type or surface.
You can get a fairly good result with such sources.
So no, you should not blindly revert its modifications.
If the estimation was really bad almost all the time why not, but here the
example given is ok.

Le sam. 18 juil. 2020 à 12:56, Michael Reichert  a
écrit :

> Hi,
>
> while reviewing changes in my local area, I discovered that user Modest7
> has been adding tracktype=* tags to lots of highway=track at various
> locations. I asked him what sources he used apart from the satellite
> imagery mentioned in the imagery_used=* tag of his changesets. See
> https://www.openstreetmap.org/changeset/87236896 for a discussion with
> him.
>
> I do not believe that one can add reliable tracktype=* information from
> satellite imagery without having some ground truth knowledge in order to
> know how to interpret the imagery in that region. Adding estimated
> tracktype=* does not help OSM on the long term. People how rely on the
> information (e.g. some wanting to drive or cycle on that track) are
> disappointed about this low-quality OSM data. Mappers who decide where
> to map assume these roads to be mapped properly. IMHO, adding
> fixme=resurvey tracktype will not improve it. Data consumers usually do
> not use tags like fixme=* In the case of imports (another type of mass
> editing), we say that an import must not add fixme=* to cover
> shortcomings of the data to be imported because they usually do not get
> fixed in a reasonable time. Therefore, I plan to revert these changes.
>
> Modest7 does not seem to realise that estimating tracktype from
> satellite imagery is not doing a service to OSM. I am currently
> preparing a revert of all additions of surface=* and tracktype=* by him
> he uploaded since 1 January 2020 [1]. The revert will only edit tags,
> geometry will stay unchanged. I revert changes on surface as well
> because that's not very different to tracktype except that it applies to
> other types of roads as well.
>
> The countries which will be affected are:
> Germany
> Denmark
> Turkey
> United States
> Poland
> Ukraine
> Morocco
> Czech Republic
> Lithuania
> Sweden
> Norway
> eSwatini
>
> A changeset discussion with him can be found at
> https://www.openstreetmap.org/changeset/87236896
>
> Best regards
>
> Michael
>
>
> [1] This date is not fixed yet.
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>


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

Re: [Talk-us] [Talk-us-newyork] Interested in importing address points in New York State

[Skyler Hawthorne]

Well, it turned it to be a lot easier than I was thinking it would be! I 
reached out to the contact listed on the Clearing House web site, using the 
template in the wiki page, and he replied confirming that we have 
permission to use the data. This is the text of the email exchange, and 
I've also attached the raw .eml file.


From: Winters, Frank (ITS) frank.wint...@its.ny.gov
Date: July 17, 2020 22:30:24
Subject: RE: Interested in importing the Address Point data from the 
Clearing House into OpenStreetMap

To: Skyler Hawthorne o...@dead10ck.com
CC: Coryell, Rodger (ITS) rodger.cory...@its.ny.gov, Fargione, Craig (ITS) 
craig.fargi...@its.ny.gov


Hi Skyler, nice to hear form you. We would very much like the SAM address 
points to be included in Open Street Map. The permitted use of the points 
is quite simple. You may use the points for any lawful purpose. While we do 
our best to maintain a comprehensive and accurate set of address points 
with our limited resources we know it has shortcomings. See the metadata 
for the liability disclaimer.


We generally post quarterly updates to the data set.


Frank Winters
Geographic Information Officer

Office of Information Technology Services
W. Averell Harriman State Office Campus
Bldg. 5 - Floor 1
Albany, NY 12226
518.242.5036 | 518.281.9140 m | frank.wint...@its.ny.gov


-Original Message-
From: Skyler Hawthorne  Sent: Friday, July 17, 2020 6:30 PM
To: Winters, Frank (ITS) 
Subject: Interested in importing the Address Point data from the Clearing 
House into OpenStreetMap


ATTENTION: This email came from an external source. Do not open attachments 
or click on links from unknown senders or unexpected emails.


Hello Mr Winters,

Thank you for your part in making the GIS data for New York State available 
to the public through the Clearing House project!


I am a contributor to the OpenStreetMap project [1], a collaborative open 
project to create a global geodata set freely usable by anyone [2].


We respect the IP rights of others and I write to ask if we can use this 
data. There does not appear to be any explicit information about the 
license under which the data sets in the Cleaning House web site are 
distributed. It's unclear what the terms are for its use, and specifically 
whether or not it is public domain, and if it is permitted to import into 
the OpenStreetMap project and redistribute to the world under an open license.


At the most simple, I would seek a statement like this:

"The New York State GIS Program Office [or the relevant NYS department(s)] 
has no objections to geodata derived in part from the GIS Clearing House 
data sets being incorporated into the OpenStreetMap project geodata 
database and released under a free and open license" [1]


I also ask that whatever statement you are prepared to make can be made 
public for information purposes.


Below is a fact sheet. If you would like any more information, I will do my 
best to help or can ask our project's License Working Group to get in touch 
with you.


Regards,
Skyler Hawthorne

Fact Sheet

[1] The OpenStreetMap project currently has over 750,000 registered 
contributors worldwide. Our main website is https://www.openstreetmap.org


[2] We are mandated to make our geodata available in perpetuity under a 
free and open licence. We are not allowed to use a commercial license, but 
commercial organisations are allowed to use our data under similar terms.


[3] Our data is currently published under the Open Database License 1.0, 
https://protect2.fireeye.com/v1/url?k=76761582-2a4eb33f-7674ecb7-000babd9fa3f-f71edf933744da0d=1=391ef603-5912-439f-b6e4-b8ac749598bd=http%3A%2F%2Fwww.opendatacommons.org%2Flicenses%2Fodbl%2F


[4] Most of our geodata is contributed by individuals. However, we are very 
grateful when able to incorporate or derive from other geo-data datasets 
where license terms are compatible.


[5] We formally attribute all such sources at 
https://wiki.openstreetmap.org/wiki/Attribution, using any specific wording 
if you request. We also try to provide a link to this page with any extract 
of data from our database. However, for reasons of practicality, we do not 
require end-users to repeat such attribution since it runs into hundreds.


[6] We also keep a public track of third party data use at 
https://wiki.openstreetmap.org/wiki/Import/Catalogue and usually have a 
project page for each dataset, describing how we use it and whether there 
are any license restrictions to be aware of.


[7] If you have any specific legal questions, the OpenStreetMap 
Foundation's License Working Group can be reached at 
le...@osmfoundation.org and will be glad to help.

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

Re: [Talk-GB] National Cycle Network removal/reclassification

[Adam Snape]

On the subject of overlapping relations. I've recently noticed that the NCN
62 relation has been named Transpennine trail which is true for much, but
not all of the route. The TPT ends at Southport, yet NCN 62 continues
further North. At the eastern end of the TPT goes far beyond the end of NCN
62 which ends at Selby. They need to be two separate relations.

I generally just use ID and it seems very time consuming to fix one section
at a time using ID, but I'm sure there's an easier way using JOSM or
something! If anybody with a better grasp than me of the tools could
correct this it would be much appreciated.

Kind regards,

Adam

On Sat, 18 Jul 2020, 14:49 Richard Fairhurst,  wrote:

> Hi all,
>
> As some of you may be aware, Sustrans has embarked on a project to review
> and improve the National Cycle Network.
>
> As part of this, sections of routes which Sustrans thinks have no
> realistic prospect of being brought up to a minimum standard in the near
> future are being either removed from the network entirely, or
> "reclassified" - which in practice means that they might still be
> signposted as cycle routes, but not with an NCN number, and probably
> maintained/promoted by local authorities rather than by Sustrans.
> Generally, these are minor roads where the level of traffic is too high.
>
> For example, the Avon and Wiltshire circular cycleways (currently NCN 410
> and 254 respectively) will be reclassified out of the NCN, while the routes
> in Rutland have been pretty much removed entirely.
>
> Sustrans' own website mapping has just been updated to take account of
> this, which you can see at https://osmaps.ordnancesurvey.co.uk/ncn . The
> dashed lines are reclassified, while some sections have been removed
> entirely.
>
> It's not currently released under an open licence so not suitable for
> direct inclusion into OSM. I will see if I can get permission for the data
> to be used.
>
> I believe that "re-signing" will be starting imminently so you may start
> to see route signs removed, or the numbers being patched over, or replaced
> with route logos or names. At which point, of course, it's fair game for
> OSM.
>
> Where a section of route has been removed, it'll be a straightforward case
> of removing it from the relation (or on occasion deleting an entire
> relation). Where one has been reclassified, I suspect the tagging decision
> is less clear. Sometimes we might want to move it to a new relation with
> network=rcn or network=lcn; sometimes I suspect there could be a case for
> keeping it in the existing relation with a 'link' role; sometimes we may
> want to have two partly overlapping relations, one for the now shortened
> NCN route, another for the full named route (e.g. NCN 78 vs the Caledonian
> Way). There may even be cases where a route is removed from the NCN but
> remains as a EuroVelo route.
>
> cheers
> Richard
> [writing in a personal capacity only etc. etc.]
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-it] [talk-it] cabina ascensore troppo piccola per bici normale

[Francesco Ansanelli]

Ciao Volker,

questione interessante per l'accessibilità in generale e non solo per le
biciclette. Vista la tridimensionalità degli oggetti, credo sia meglio
usare:
maxwidth=*, maxlenght=* e maxheight=*.
Nel caso specifico dell'ascensore si può aggiungere anche: maxweight=*, che
banalmente è anche il più facile da ricavare in quanto indicato sulla
targhetta insieme alla capacità massima (persone senza bici ).
Sono tutti tag esistenti e che non lasciano dubbi se si dovessero adottare
per il caso in questione.

Buona giornata
Francesco

Il sab 18 lug 2020, 16:05 Volker Schmidt  ha scritto:

> Le cabine degli ascensori sono spesso troppo piccole per bici normali,
> salvo se si mettano in verticale. Come si fa?
> Il problema è presente in migliaia di ascensori nelle stazioni ferroviarie.
> Il problema del tagging è che una bici corta ci sta, una bici di lunghezza
> normale ci sta solo in verticale.
> In più bicycle=no (o varianti) non sarebbe corretto in ogni caso, perché
> non è vietato salire con la bici, ma si tratta di un limite meccanico. In
> più non è che non si può salire con la bici, ma bisogna sapere come tenerla
> in verticale.
>
> Si potrebbe indicare una lunghezza massima per la bici
> : "bicycle:maxlength=1.6"
> o le dimensioni della cabina "length=1.6; width=1.2".
>
> Qualcuno ha già affrontato la mappatura sotto questo aspetto.?
>
> Volker
>
>
> Qualcuno ha già provato una mappatura?
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk] Planned revert of added surface and tracktype tags without local knowledge in various countries

[stevea]

On Jul 18, 2020, at 7:09 AM, Rory McCann  wrote:
> In addition (I can't find the link now but) I recall reading about the death 
> of a hiker or climber who used some app which used OSM data, and the app 
> didn't distinguish between track_types (or there was no track_type data for 
> that route), so the hiker presumed it was OK to go on, and subsequently died.

Let us be clear as crystal as we pause to realize the key part of this:  "so 
the hiker presumed it was OK."  The hiker made that choice. Any assumption that 
OSM has ANYthing to do with a subsequent death is specious and only that:  an 
assumption.

No, maps don't "make people" do foolish things.  Yes, people do foolish things, 
by their own volition.  Not because "the GPS made me do it" or "the map is 
responsible" (somehow).  OSM makes no warranties as to fitness or 
merchantability for any particular purpose.  Do I (we) really need to say this? 
 It's sad if we do.

I recently had someone from my local Land Trust imply that because I entered 
trails under development from their public map (and tagged access=no) that 
somehow OSM was responsible for increased trespassing.  Ridiculous.  Maps don't 
make people choose to break the law, people do.  I set him straight and we get 
along fine.

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

Re: [OSM-talk] Planned revert of added surface and tracktype tags without local knowledge in various countries

[Rory McCann]

In addition (I can't find the link now but) I recall reading about the 
death of a hiker or climber who used some app which used OSM data, and 
the app didn't distinguish between track_types (or there was no 
track_type data for that route), so the hiker presumed it was OK to go 
on, and subsequently died.


On 18.07.20 16:01, Andy Townsend wrote:

On 18/07/2020 11:53, Michael Reichert wrote:

I do not believe that one can add reliable tracktype=* information from
satellite imagery without having some ground truth knowledge in order to
know how to interpret the imagery in that region.


I think that "without having some ground truth knowledge" is the key 
part there.  I know from personal experience that if I was to try and 
add tracktype or detailed surface information based purely on imagery 
I'd get it wrong lots of the time.  Very often when I'm updating OSM 
I'll add the details that I recorded while I was there, and look at what 
they say and what it looks like on the available imagery and the two can 
be very different.


Best Regards,

Andy



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


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

[Talk-it] [talk-it] cabina ascensore troppo piccola per bici normale

[Volker Schmidt]

Le cabine degli ascensori sono spesso troppo piccole per bici normali,
salvo se si mettano in verticale. Come si fa?
Il problema è presente in migliaia di ascensori nelle stazioni ferroviarie.
Il problema del tagging è che una bici corta ci sta, una bici di lunghezza
normale ci sta solo in verticale.
In più bicycle=no (o varianti) non sarebbe corretto in ogni caso, perché
non è vietato salire con la bici, ma si tratta di un limite meccanico. In
più non è che non si può salire con la bici, ma bisogna sapere come tenerla
in verticale.

Si potrebbe indicare una lunghezza massima per la bici
: "bicycle:maxlength=1.6"
o le dimensioni della cabina "length=1.6; width=1.2".

Qualcuno ha già affrontato la mappatura sotto questo aspetto.?

Volker


Qualcuno ha già provato una mappatura?
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk] Planned revert of added surface and tracktype tags without local knowledge in various countries

[Andy Townsend]

On 18/07/2020 11:53, Michael Reichert wrote:

I do not believe that one can add reliable tracktype=* information from
satellite imagery without having some ground truth knowledge in order to
know how to interpret the imagery in that region.


I think that "without having some ground truth knowledge" is the key 
part there.  I know from personal experience that if I was to try and 
add tracktype or detailed surface information based purely on imagery 
I'd get it wrong lots of the time.  Very often when I'm updating OSM 
I'll add the details that I recorded while I was there, and look at what 
they say and what it looks like on the available imagery and the two can 
be very different.


Best Regards,

Andy



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

[Talk-GB] National Cycle Network removal/reclassification

[Richard Fairhurst]

Hi all,

As some of you may be aware, Sustrans has embarked on a project to review and 
improve the National Cycle Network.

As part of this, sections of routes which Sustrans thinks have no realistic 
prospect of being brought up to a minimum standard in the near future are being 
either removed from the network entirely, or "reclassified" - which in practice 
means that they might still be signposted as cycle routes, but not with an NCN 
number, and probably maintained/promoted by local authorities rather than by 
Sustrans. Generally, these are minor roads where the level of traffic is too 
high.

For example, the Avon and Wiltshire circular cycleways (currently NCN 410 and 
254 respectively) will be reclassified out of the NCN, while the routes in 
Rutland have been pretty much removed entirely.

Sustrans' own website mapping has just been updated to take account of this, 
which you can see at https://osmaps.ordnancesurvey.co.uk/ncn . The dashed lines 
are reclassified, while some sections have been removed entirely.

It's not currently released under an open licence so not suitable for direct 
inclusion into OSM. I will see if I can get permission for the data to be used.

I believe that "re-signing" will be starting imminently so you may start to see 
route signs removed, or the numbers being patched over, or replaced with route 
logos or names. At which point, of course, it's fair game for OSM.

Where a section of route has been removed, it'll be a straightforward case of 
removing it from the relation (or on occasion deleting an entire relation). 
Where one has been reclassified, I suspect the tagging decision is less clear. 
Sometimes we might want to move it to a new relation with network=rcn or 
network=lcn; sometimes I suspect there could be a case for keeping it in the 
existing relation with a 'link' role; sometimes we may want to have two partly 
overlapping relations, one for the now shortened NCN route, another for the 
full named route (e.g. NCN 78 vs the Caledonian Way). There may even be cases 
where a route is removed from the NCN but remains as a EuroVelo route.

cheers
Richard
[writing in a personal capacity only etc. etc.]
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-it] Landuse

[Ivo Reano]

Per la mappatura dei landuse il mio approccio prevede una preparazione.

Migliorare i tracciati di strade e corsi d'acqua, spesso sono mappate con
spigoli assurdi e zig zag dovuti (penso) all'utilizzo di tracce gps fatte
in bici o a piedi.

Poi traccio delle parallele alle way con una larghezza in funzione della
larghezza delle way.

Ragionevolmente sposto nelle zone dove le ortofoto fanno vedere slarghi e
incroci
... e costruisco le aree interne come landuse.

Ivo/Jrachi


Il giorno sab 18 lug 2020 alle ore 15:09 Simone Saviolo <
simone.savi...@gmail.com> ha scritto:

> Sono d'accordo anch'io: la strada non è né residential né farmland né
> industrial :)
>
> Ciao,
>
> Simone
>
> Il giorno ven 10 lug 2020 alle ore 14:53 Manuel 
> ha scritto:
>
>> Cambio oggetto perché la discussione ormai è su altro.
>> Dunque, ci ho pensato a lungo e devo ammettere che l'approccio di Martin
>> mi sembra adatto, considerato che anche per il landuse=farmland facevo già
>> la stessa cosa, evitando di "coprire" strade e masse d'acqua.
>>
>> Manuel
>> Il 30/06/2020 10:45, Martin Koppenhoefer ha scritto:
>>
>>
>>
>> Am Mo., 29. Juni 2020 um 13:58 Uhr schrieb Manuel > >:
>>
>>> Sono d'accordo sul parco, ma per il resto l'uso di un landuse che
>>> comprenda tutta la zona residenziale del paese è molto esteso (anche in
>>> Germania - che spesso è presa a esempio - l'uso del landuse=residential è
>>> fatto in modo simile - es. la zona residenziale di Heidelberg
>>> ).
>>>
>>
>>
>>
>> infatti, sto cercando di convincere anche i tedeschi ;-)
>>
>> Ciao
>> Martin
>>
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[OSM-talk-fr] exporter le wiki osm

[Baptiste Lemoine - Cipher Bliss]

Hello les gens,
j'ai vu qu'il était possible de faire des exports de wikipedia 
https://dumps.wikimedia.org/frwiki/latest/ , et me demandais si on pouvait 
aussi faire ça avec le wiki OSM.Pour des questions de résilience en cas de 
pépin et pour continuer à s'instruire en hors ligne, ça me semble être un truc 
essentiel à mettre à disposition.
librement vôtre,

Baptiste LEMOINE - Dirigeant de Cipher Bliss.com , N° SIRET: 79942416300035
---
Tel 0185461173  / Signal 0627130837 , Telegram: Tykayn , Mastodon: @tykayn, 
Riot: @tykaynchu:matrix.org
GPG: 64A8 9B18 65E6 6523 FD86 7CB5 8796 1FCA F978 54FF
clé publique monnaie-libre Duniter / Ğ1: 
8c4mVVPAHd4yLYcxWM4U8Z3zUb4WpRX1iGtX5T7tbEFE - tykayn

Sent with ProtonMail Secure Email.

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

Re: [Talk-it] Landuse

[Simone Saviolo]

Sono d'accordo anch'io: la strada non è né residential né farmland né
industrial :)

Ciao,

Simone

Il giorno ven 10 lug 2020 alle ore 14:53 Manuel  ha
scritto:

> Cambio oggetto perché la discussione ormai è su altro.
> Dunque, ci ho pensato a lungo e devo ammettere che l'approccio di Martin
> mi sembra adatto, considerato che anche per il landuse=farmland facevo già
> la stessa cosa, evitando di "coprire" strade e masse d'acqua.
>
> Manuel
> Il 30/06/2020 10:45, Martin Koppenhoefer ha scritto:
>
>
>
> Am Mo., 29. Juni 2020 um 13:58 Uhr schrieb Manuel :
>
>> Sono d'accordo sul parco, ma per il resto l'uso di un landuse che
>> comprenda tutta la zona residenziale del paese è molto esteso (anche in
>> Germania - che spesso è presa a esempio - l'uso del landuse=residential è
>> fatto in modo simile - es. la zona residenziale di Heidelberg
>> ).
>>
>
>
>
> infatti, sto cercando di convincere anche i tedeschi ;-)
>
> Ciao
> Martin
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [talk-au] Working with local government

[Sebastian Spiess]

On 9/7/20 7:52 pm, Mateusz Konieczny via Talk-au wrote:
>
>
>
> Jul 9, 2020, 06:50 by greg.dutkow...@gmail.com:
>
> Hi,
> Bicycle Network Tasmania are trying to improve the quality of
> cycling infrastructure information in OSM.
> Much has been done by volunteers in various jurisdictions, and we
> have done lots locally, but the tagging is quite complex for cycle
> paths and not always correct.
> Local councils are responsible for much of the infrastructure, but
> they usually have little interaction with OSM.
> It would be most efficient if the councils GIS data worked in
> tandem with OSM data so that they kept each other up to date, each
> storing the info that is most useful for them. For instance, for
> bike parking, there is little utility in OSM storing the asset
> numbers and other info that the councils use to maintain their
> assets (although the ref tag could be used as a foreign key to
> help keep the two in sych).
> The Hobart councils we work with are concerned with the quality of
> the data in OSM and the ability of anyone to change it.
> Does anyone know of any examples we could learn from of local
> government itself working to keep OSM data up to date?
> Thanks.
>
> One of the easiest things that local government may do is to
>
> 1) publish their datasets on an open license allowing to use it by mappers
> 2) react to reports of mistakes in their data
>
> Both work relatively well in Poland for address data - with publishing
> required by
> national law (though still ignored be many local governments)
>
> Note that (1) is useful for mappers even if data quality is
> unsufficient to import it
> into OSM. I am using a bit noisy bicycle parking in locating unmapped ones
> (often location, description and real location mismatches
> significantly, but
> almost always it allows me to find something that was missing in OSM)
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au

Hi, indeed great to see you reach out.

Yes I agree that a good approach is to make the data open. However, I
understand Greg is asking if there are working concepts on how to
maintain a link between local government GIS (which might have
additional information) and OSM data.

Once the relevant information has been entered into OSM, how is the
council to track the data? e.g. to see if tags get modified, nodes
moved, added.

e.g. worst case is that a nicely mapped and tagged area gets re-done by
someone. This results in new node and way numbers.

A good example would be a single node gets expanded by OSM users.

In both cases the data is diverging from another. How to keep track? Are
there concepts/solutions?

Yes

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

Re: [OSM-talk-fr] API indisponible ?

[Gad Jo]

C'était probablement lié à une erreur de configuration chez cloudflare et ça à 
perduré pendant quelques dizaine de minutes.

https://blog.cloudflare.com/cloudflare-outage-on-july-17-2020/

Le July 17, 2020 10:10:39 PM UTC, Jacques Lavignotte  a 
écrit :
>
>
>Le 17/07/2020 à 23:29, Gaël Simon a écrit :
>
>> api.openstreetmap.org n’a pas pu être résolu.
>
>Résolu en 6 et en 4.
>
>J.
>
>api.openstreetmap.org. 286 IN  A   130.117.76.13
>api.openstreetmap.org. 286 IN  A   130.117.76.12
>api.openstreetmap.org. 286 IN  A   130.117.76.11
>
>Non, rien.
>
>
>-- 
>GnuPg : 156520BBC8F5B1E3 Because privacy matters.
>« Quand est-ce qu'on mange ? » AD (c) (tm)
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

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

[OSM-talk] Planned revert of added surface and tracktype tags without local knowledge in various countries

[Michael Reichert]

Hi,

while reviewing changes in my local area, I discovered that user Modest7
has been adding tracktype=* tags to lots of highway=track at various
locations. I asked him what sources he used apart from the satellite
imagery mentioned in the imagery_used=* tag of his changesets. See
https://www.openstreetmap.org/changeset/87236896 for a discussion with him.

I do not believe that one can add reliable tracktype=* information from
satellite imagery without having some ground truth knowledge in order to
know how to interpret the imagery in that region. Adding estimated
tracktype=* does not help OSM on the long term. People how rely on the
information (e.g. some wanting to drive or cycle on that track) are
disappointed about this low-quality OSM data. Mappers who decide where
to map assume these roads to be mapped properly. IMHO, adding
fixme=resurvey tracktype will not improve it. Data consumers usually do
not use tags like fixme=* In the case of imports (another type of mass
editing), we say that an import must not add fixme=* to cover
shortcomings of the data to be imported because they usually do not get
fixed in a reasonable time. Therefore, I plan to revert these changes.

Modest7 does not seem to realise that estimating tracktype from
satellite imagery is not doing a service to OSM. I am currently
preparing a revert of all additions of surface=* and tracktype=* by him
he uploaded since 1 January 2020 [1]. The revert will only edit tags,
geometry will stay unchanged. I revert changes on surface as well
because that's not very different to tracktype except that it applies to
other types of roads as well.

The countries which will be affected are:
Germany
Denmark
Turkey
United States
Poland
Ukraine
Morocco
Czech Republic
Lithuania
Sweden
Norway
eSwatini

A changeset discussion with him can be found at
https://www.openstreetmap.org/changeset/87236896

Best regards

Michael


[1] This date is not fixed yet.



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

Re: [talk-au] LPI NSW images not loading

[Warin]

On 18/7/20 8:13 pm, Sebastian Spiess wrote:

Hello,

is anyone else having issues with NSW LPI images not loading in JOSM?

This also seems to be the case for iD.


Yep. Either 'they' have changed something or 'they' have a problem.
Give them 24 hours to see if it is a problem .. if not working then it will be 
some change they have made.

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

Re: [talk-au] LPI NSW images not loading

[Andrew Davidson]

On 18/7/20 8:13 pm, Sebastian Spiess wrote:

Hello,

is anyone else having issues with NSW LPI images not loading in JOSM?

This also seems to be the case for iD.


Their main website also seems to be down at present:

https://www.spatial.nsw.gov.au/

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

[talk-au] LPI NSW images not loading

[Sebastian Spiess]

Hello,

is anyone else having issues with NSW LPI images not loading in JOSM?

This also seems to be the case for iD.

Regards,

Seb



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

Re: [Talk-es] Ediciones del usuario jamesks

[Roberto geb]

Si todos los cambios al mapa tuvieran que ser perfectos el mapa no
existiría. El trabajo en OSM es colaborativo y evolutivo: unos añaden vías
principales a alto nivel, otros añaden algunas calles, otros las completan,
otros ponen nombres a las calles, otros números de casas, otros añaden las
casas, otros cargan los datos del catastro con información tridimensional,
otros ponen pasos de cebra, cubos de reciclado, señales de tráfico,
comercios,  ... hay tanto que hacer para que el trabajo sea completo que no
veo porqué criticamos a alguien por añadir información en donde la había,
en vez de trabajar para completar el mapa.
La geometría es fractal y JOSM incluye funciones para añadir detalles en
las vías.
Otro tema es añadir objetos y no corregir los errores detectados, pero en
mi opinión jamesks ha contribuido y contribuye de forma importante en el
desarrollo del mapa.

El jue., 9 jul. 2020 a las 17:28, Carlos Antonio Rivera (<
carlos.kapa...@gmail.com>) escribió:

> Buenas tardes,
> me parece un tema interesante a debatir ya que se ha hablado bastantes
> veces en Telegram sobre este tipo de situaciones que nos encontramos con
> algunos usuarios, que tienen su forma de mapear y que en muchas cosas no
> cumplen con la comunidad o en algunos casos hacen caso omiso a cualquier
> comentario (no lo digo en concreto por jamesks).
> No podemos permitir que unos pocos usuarios dificulten o destruyan el
> trabajo de los demás en algo colaborativo como OSM, donde mayormente
> trabajamos de forma altruista y por diversión. Lo último de lo que tenemos
> ganas es de estar perdiendo el tiempo revisando lo que otros hacen, de
> entrar en enfrentamientos o en discusiones como esta.
>
> Como comunidad tenemos que seguir unos mínimos para que nuestro trabajo no
> entre en conflicto con el de los demás y sea realmente colaborativo, que es
> de lo que se trata. No es aceptable que se salten reglas establecidas para
> el bien de todos, que se considere el mapa propio o se ignore al resto de
> usuarios en ningún momento.
> Tenemos multitud de herramientas para ayudarnos a mapear y revisar
> nuestras ediciones, a parte de que siempre se puede preguntar en caso de
> duda.
> Todos hemos cometido multitud de errores como novatos y también los
> seguiremos cometiendo puesto que somos humanos y no lo hacemos todo a la
> perfección, pero creo que la gran mayoría tratamos de aprender y hacerlo lo
> mejor posible.
>
> Sobre jamesks conozco lo que se dice en esta página de contribuciones
> http://hdyc.neis-one.org/?jamesks, que ha mapeado mucho por España y que
> a todos nos ha dado algún quebradero de cabeza por la gran cantidad de
> problemas que deja en el mapa.
> Mi sensación es de que mapea a gran escala y quizás no sea una persona
> perfeccionista, sino que quiere añadir la mayor cantidad de datos posibles
> en el menor tiempo.
> Con ese estilo de mapeo puedo estar de acuerdo en según que cosas que
> después de mapear sean fácilmente mejorables y revisables, sobre todo que
> sean por él mismo, no dejarle el fregado a otros.
> No puedo decir haber visto que revise sus ediciones, y con el gran número
> de errores que tiene en gran parte de ellas esto es un gran problema para
> la comunidad.
> Véase por ejemplo Osmose https://osmose.openstreetmap.fr/en/byuser/jamesks.
> A día de hoy según http://hdyc.neis-one.org/?jamesks tiene algo más de
> 83.000 errores (cuidado con esto que todos no son suyos, pero es
> orientativo de los datos que toca y que tampoco corrige).
>
> Creo que es necesario que este usuario comprenda que no puede seguir
> editando de esta manera y que es imprescindible que revise sus ediciones, a
> ser posible bastantes de las que ya ha hecho.
> Se ha llegado ya a un punto en el que hemos visto que nos va a llevar más
> trabajo corregir que hacer de nuevo lo que ha hecho en muchos casos. Por
> otra parte para revisar todos esos problemas que lleva arrastrando desde
> hace tiempo nos llevaría muchísimo tiempo, que no tenemos por qué dedicar,
> ya que no es nuestro trabajo y tenemos otras cosas que hacer al igual que
> él.
>
> Espero que consigamos que este tipo de problemas que crean algunos
> usuarios se puedan frenar antes para que no se agrave la situación por el
> bien de los demás, ya que algunos pueden cansarse o incluso dejar OSM por
> la insistencia de unos pocos de no hacer bien las cosas y/o no querer
> colaborar, sino ir a su rollo.
>
> Un saludo
>
>
> El jue., 9 jul. 2020 a las 15:58, José Juan Montes ()
> escribió:
>
>>
>> +1, tb he comentado en el changeset.
>>
>> Jose Juan Montes
>>
>>
>> El jue., 9 jul. 2020 a las 14:39, Diego Cruz ()
>> escribió:
>>
>>> Hola a todos:
>>>
>>> Os escribo porque estos días de atrás también ha habido cierto debate
>>> sobre la imprecisión de las ediciones del usuario jamesks que ha quedado un
>>> poco diluido entre otras cuestiones.
>>>
>>> Hace tiempo que en Castilla y León comentamos lo hartos que estamos de
>>> las vías generadas por este usuario, porque edita sin hacer 

Re: [OSM-talk-fr] Relation : multiples … ca existe ?

[Denis Chenu]

Merci, merci , merci …

Donc : si de multiples éléments font parti d'un ensemble : j'ajoute un
polygone avec son amenity.
C'est bien cela le principe ?

Si (au final) ce batiment : https://www.openstreetmap.org/way/79966828
fait parti du Jardin, mais avec juste un chemin entre les 2.
1. Est ce que cela vaut la coup de l'ajouter
2. Comment faire ?

Denis
Le 18/07/2020 à 01:51, Jérôme Amagat a écrit :
> Tout ce trouve dans un polygone donc il ne faut pas une relation mais
> un polygone avec à l'intérieur les bâtiments, le jardin, le
> recycleur... et on sait que le composteur et les bâtiments font partie
> du "Jardin du Hêtre" parce qu'ils sont à l'intérieur, par contre il
> faut y mettre les bon tags dessus à part le nom. Je pense que c'est
> surtout un jardin donc le tag principal leisure=garden convient. J'ai
> modifié le polygone https://www.openstreetmap.org/way/787565928 et
> supprimé la relation.
>
> Le ven. 17 juil. 2020 à 15:25, Denis Chenu via Talk-fr
> mailto:talk-fr@openstreetmap.org>> a écrit :
>
> Bonjour,
>
> J'ai une difficulté sur une relations, je ne sais pas comment la
> placer.
> L'ensmble fait partie d'un seul élément "Jardin du Hétre"
> La relation est la suivante
> 1. Deux bâtiments coté rue
> 2. 1 bâtiment intérieur (et plus)
> 2. Une zone jardin (1 deuxième zone à construire)
> 3. Un recycleur (compost partagé)
>
> 
> https://www.openstreetmap.org/?mlat=50.69923=3.16242#map=19/50.69923/3.16242
> Pour l'instant : j'ai un multipolygone "Jardin du Hétre" en plus du
> jardin "Jardin du Hétre" et du composteur "Jardin du Hétre" …
>
> On peut faire autrement ? Par exemple : indiquer quel est la partie du
> batiment coté rue qui est l'entrée ?
>
> Merci
>
> ___
> 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-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] MapContrib en Allemand pour le projet Karto-District

[Vincent Bergeot]

Bonjour,

dans le cadre du projet franco-allemand KartoDistrict 
(https://kartodistrict.eu), l'allemand a été ajouté à MapContrib (merci 
Lioba, Benoît et Guillaume).


C'est l'occasion de donner quelques nouvelles :

 * l'instance principale (dont le transfert sur les serveurs de
   l'association OSM-fr n'a toujours pas été effectué par manque de
   temps) mapcontrib.xyz continue ses 20 ou trente visiteurs
   (contributeurs) quotidiens, répartis un peu partout dans le monde
   (quelques explosions pendant le confinement du coté des philippines
   et du japon dans mon souvenir / aucun véritable suivi de tout cela
   n'est fait malgré un matomo qui tourne sur le site)
 * nous avons, il y a quelques temps (année), décidé de ne pas
   continuer le développement de cette V1 pour basculer sur la version
   "Next" (en particulier les choix techniques et de construction
   générale qui ont été repensé / moi pas le principal penseur de
   l'histoire !!!)
 * la V1 tourne toujours (sans doute des choses à mettre à jour
   https://github.com/mapcontrib/mapcontrib) mais elle fait son taf !
 * la version Next est plutôt à l'arrêt
   (https://gitlab.com/mapcontrib/mapcontrib.next) principalement car
   le dev principal (Guillaume à de très rares exceptions est bénévole
   sur toute la partie dev de Next) à d'excellentes priorités qui lui
   prennent du temps la nuit !
 * cela ne veut pas dire que c'est fini mais cela prend son temps
 o un labo de clermont a embauché un dev pour avancer dessus car
   des besoins de cartes de contributions thématiques,
 o quelques pistes à droite ou à gauche mais c'est beaucoup de bout
   de ficelles et peu de temps (y compris par exemple pour chercher
   des financements) !
 * dans les étapes dont je rêve (sans ordre particulier) :
 o un assistant de requête overpass à la "quickOSM" (module de qgis)
 o récupérer un item osmose et pouvoir faciliter soit les
   corrections (osmose-QA) soit l'ajout de données ouvertes (osmose-OD)
 o un meilleur support pour les traductions (usages réguliers de la
   V1 dans des pays "non-supportés")
 o du temps pour documenter tout cela

Je communique peu autour de MapContrib (ni le temps, ni la compétence, 
ni l'envie véritable !) mais cette mise à jour allemande était l'occasion.


Au passage ce projet a permis la tenue d'une table ronde sur la 
cartographie transfrontalière filmée (Frédérick Ramm, Kristine Karch et 
moi même étions les "experts" OSM, merci à DenisH pour les mises en 
lien). Cette vidéo devrait être visible dans un moment, lorsque le 
montage avec les traductions sera finalisé. En attendant vous pouvez 
aller voir cette vidéo de présentation d'OSM : 
https://kartodistrict.eu/index.php/ExpertVideos#OpenStreetMap).


Bonne journée

--
Vincent Bergeot

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