Re: [Talk-us] place=neighborhood on subdivisions?

[Joseph Eisenberg]

Settlements which are mapped with the place=* key are usually mapped as a
node, not as an area.

There are many place=city areas in the USA, but that's because the tag was
incorrectly added to many municipal boundaries when they were first
imported, years ago.

Some neighborhoods have well-defined boundaries, such as
boundary=administrative relations, and can be mapped as such.

But most neighborhoods, like towns and villages, do not have a clear place
where the named place ends. Even in big cities with well-known
neighborhoods you will hard-pressed to get two locals to agree about the
exact place where one named neighborhood ends and another starts, unless
this is legally defined by the municipality (and even then, real estate ads
and locals will often change things).

So it's best to use place=neighbourhood, like place=town and place=suburb,
on a node at the center of the place.

- Joseph Eisenberg

On Tue, Sep 22, 2020 at 6:41 PM Paul Johnson  wrote:

>
>
> On Tue, Sep 22, 2020 at 8:36 PM Mike N  wrote:
>
>> On 9/22/2020 9:26 PM, Paul Johnson wrote:
>> > The extra hamlet nodes are import remainders that haven't yet
>> been
>> > converted to landuse areas.   The general landuse zones for that
>> area
>> > have been identified, but do not exactly correspond to the named
>> > subdivisions.   As I get a chance to survey, I divide the landuse
>> into
>> > subdivisions and convert the node to a named area for the
>> subdivision.
>> >
>> >
>> > Please don't expand these as landuse, please expand them as
>> > place=neighborhood instead.  Landuse polygons should be congruent to
>> the
>> > actual land use.
>>
>> That's a good point: the subdivisions often contain one or more landuse
>> basins, clusters of trees, etc.   I've been thinking of them as one big
>> blob, but it seem correct on a more micromap level to mark them as
>> place=, and identify the smaller landuse areas (which are sometimes all
>> residential).
>>
>
> Exactly.  My rule of thumb is if you're thinking about putting a name on
> it, and it's not a shopping center, apartment complex or similar large but
> contiguous landuse, then landuse=* probably isn't what your polygon should
> be.
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] place=neighborhood on subdivisions?

[Paul Johnson]

On Tue, Sep 22, 2020 at 9:27 PM stevea  wrote:

> On Sep 22, 2020, at 7:05 PM, Clifford Snow 
> wrote:
> > For example, in Seattle I lived in the Wallingford Neighborhood. Seattle
> has defined boundaries for each of the neighborhoods. In other areas,
> neighborhoods are roughly defined by people living there. In those cases
> using a place= tag makes more sense.
>
> Clifford:  One more thing.  Several summers ago, I lived at / house sat at
> my sister's house in the Magnolia suburb of Seattle.  I believe I mapped
> fairly well the little "village downtown" there (it was walking distance,
> as a nice suburb or neighborhood might be) as a hobby after I fed her cats,
> I'd have to check OSM data history I think summer of 2012.
>
> But you'll notice that suburbs (not Neighborhoods, as you call them) of
> Seattle are tagged in OSM as place=suburb.  (And it wasn't simply me who
> has done that, I think I only did it once or twice for Magnolia and maybe
> Ballard).  In a larger city like Seattle, this seems about right.  I don't
> like disagreeing with a friend like you about where you have lived (and all
> I did was feed my sister's cat for a few weeks, and I do love Seattle) but
> I think the jury is in about Seattle suburbs in OSM, and they are tagged
> suburb.  Does Wallingford or Ballard or Magnolia get called a neighborhood
> in local vernacular?  Sure, I don't doubt it:  you just did so yourself!
> But in OSM tagging, which is I think what we're trying to better agree
> upon, I think the tagging of place=suburb on these is correct.
>

In terms of Seattle, I don't think Ballard or Magnolia are a suburb.
They're more of a neighborhood, both subordinate to Seattle.  Mercer Island
or Bellvue are more suburbs as they're their own cities but really wouldn't
matter or properly stand on their own without Seattle being in the
immediate vicinity.  Note that place=city, place=neighborhood and
place=suburb are all extant tags in common use already.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] place=neighborhood on subdivisions?

[Paul Johnson]

On Tue, Sep 22, 2020 at 8:56 PM stevea  wrote:

> If you MUST tag place=neighbourhood (note the u) see if you agree with me
> that this tag makes most sense in a hierarchy where place=suburb (and
> perhaps quarter, if applicable, is/are above) also exist(s).  I'm not
> strictly saying I believe that place=neighbourhood CANNOT exist without
> place=suburb, but it makes me wrinkle my brow a bit at it not fitting as
> well as a landuse=residential (multi)polygon might rather generically and
> innocently (without any hierarchy required) fit in.
>

Landuse=residential fits better for the lots within a place, not as a
substitute for it.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-legal-talk] Changeset Comments Copyright

[Mateusz Konieczny via legal-talk]

Sep 22, 2020, 23:43 by gi...@gmx.de:

> Hello OSMF Legal Team,
>
> due to a quite troubling revelation by @SomeoneElse that changeset comments 
> are
> automatically republished by the third party private company Slack, I would
> appreciate if you could share your legal assessment of this situation. More
> specifically, what is the copyright status of changeset comments and which 
> OSMF
> document or agreement covers changeset comments?
>
> As far as I can tell no document covers changeset comments either explicitly 
> nor
> implicitly. The Contributor Terms state that “…contributing data and/or any
> other content (collectively, “Contents”) to the geo-database of the
> OpenStreetMap project (the “Project”)” is explicitly limited to contributions 
> to
> the geo-database (map database). As far as I can tell changeset comments are 
> not
> part of the OSM's geo-database.
>
As far as I can tell changeset comments are part of the OSM's geo-database.

"Thank you for your interest in contributing data and/or any other content
(collectively, “Contents”) to the geo-database of the OpenStreetMap project 
(the “Project”)"

And yes, "any other content" clearly includes changeset description, notes,
note comments, changeset comments and so on.

Though I am unsure about status of anonymous notes, formerly possible
anonymous note comments and about user diary entries.

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

Re: [Talk-us] place=neighborhood on subdivisions?

[stevea]

On Sep 22, 2020, at 7:05 PM, Clifford Snow  wrote:
> For example, in Seattle I lived in the Wallingford Neighborhood. Seattle has 
> defined boundaries for each of the neighborhoods. In other areas, 
> neighborhoods are roughly defined by people living there. In those cases 
> using a place= tag makes more sense.

Clifford:  One more thing.  Several summers ago, I lived at / house sat at my 
sister's house in the Magnolia suburb of Seattle.  I believe I mapped fairly 
well the little "village downtown" there (it was walking distance, as a nice 
suburb or neighborhood might be) as a hobby after I fed her cats, I'd have to 
check OSM data history I think summer of 2012.

But you'll notice that suburbs (not Neighborhoods, as you call them) of Seattle 
are tagged in OSM as place=suburb.  (And it wasn't simply me who has done that, 
I think I only did it once or twice for Magnolia and maybe Ballard).  In a 
larger city like Seattle, this seems about right.  I don't like disagreeing 
with a friend like you about where you have lived (and all I did was feed my 
sister's cat for a few weeks, and I do love Seattle) but I think the jury is in 
about Seattle suburbs in OSM, and they are tagged suburb.  Does Wallingford or 
Ballard or Magnolia get called a neighborhood in local vernacular?  Sure, I 
don't doubt it:  you just did so yourself!  But in OSM tagging, which is I 
think what we're trying to better agree upon, I think the tagging of 
place=suburb on these is correct.

For the original poster's question, I think I've already stated my opinion, 
though there are certainly enough to go around!

We do a lot of landuse=residential on "neighborhoods" in the USA, especially 
without any "council" or active administration at the sub-city level.  Larger 
cities DO have these, admin_level=10 is correct on them.  Smaller cities and 
rural areas that are "a cluster of homes/houses/dwellings?"  I think a 
(multi)polygon tagged landuse=residential works well there.

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

Re: [Talk-us] place=neighborhood on subdivisions?

[stevea]

Whoops, "but NOT if it isn't something like a council"
SteveA

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

Re: [Talk-us] place=neighborhood on subdivisions?

[stevea]

Clifford:  I certainly agree with you if (and likely only if) there is 
something like a neighborhood council that actually has some sort of 
"administrative" function (which could be as "lowly" as dog catcher, mosquito 
abatement, or "sub-municipal parks department for these three neighborhood 
parks."  These are often found in larger cities, United States/Boundaries has a 
small list of examples.  But if it is more like "what the locals call it 
between 12th and Main out to the lake" (more informal, not administrative in 
any way), and it IS exclusively residential (not big or populated enough to 
contain a commercial district, though perhaps an elementary school or a 
crossroads where there is a transit stop) I'd say landuse=residental fits 
nicely.

Again, if you think place=neighbourhood works, use it, but please try to be 
true to other values of place (like suburb) which allow neighbourhood to be 
used in a sensible hierarchy.  I believe you are suggesting admin_level=10 to 
fit into a hierarchy (and sensibly, too), but if it isn't something like a 
council (however tiny and local) but not political, as there seems to be a 
sense of wards at admin_level=9 that are purely voting / electoral districts to 
being better tagged administrative=political.

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

Re: [Talk-us] place=neighborhood on subdivisions?

[Clifford Snow]

Steve,
If the boundaries exist, you could use admin_level=10.

Most of the neighborhoods I'm familiar with are just small subdivisions
within the city. For example, in Seattle I lived in the Wallingford
Neighborhood. Seattle has defined boundaries for each of the neighborhoods.
In other areas, neighborhoods are roughly defined by people living there.
In those cases using a place= tag makes more sense.

Clifford

On Tue, Sep 22, 2020 at 6:56 PM stevea  wrote:

> If you MUST tag place=neighbourhood (note the u) see if you agree with me
> that this tag makes most sense in a hierarchy where place=suburb (and
> perhaps quarter, if applicable, is/are above) also exist(s).  I'm not
> strictly saying I believe that place=neighbourhood CANNOT exist without
> place=suburb, but it makes me wrinkle my brow a bit at it not fitting as
> well as a landuse=residential (multi)polygon might rather generically and
> innocently (without any hierarchy required) fit in.
>
> SteveA
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>


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

Re: [Talk-us] place=neighborhood on subdivisions?

[stevea]

If you MUST tag place=neighbourhood (note the u) see if you agree with me that 
this tag makes most sense in a hierarchy where place=suburb (and perhaps 
quarter, if applicable, is/are above) also exist(s).  I'm not strictly saying I 
believe that place=neighbourhood CANNOT exist without place=suburb, but it 
makes me wrinkle my brow a bit at it not fitting as well as a 
landuse=residential (multi)polygon might rather generically and innocently 
(without any hierarchy required) fit in.

SteveA


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

Re: [OSM-legal-talk] Changeset Comments Copyright

[Kathleen Lu via legal-talk]

Hi GITNE,
Can you also specify what you think the problem is? I get the feeling that
you have an objection to changeset comments being posted in Slack. I'm
assuming such comments appear in the OSMUS slack group which is popular
with mappers. Why do you think this is a bad thing?
(To be clear, I think your premise is wrong and that the definition of
"Contents" in the Contributor Terms clearly includes changeset comments.)
-Kathleen


On Tue, Sep 22, 2020 at 5:19 PM Clifford Snow 
wrote:

>
>
> On Tue, Sep 22, 2020 at 2:43 PM GITNE  wrote:
>
>> Hello OSMF Legal Team,
>>
>> due to a quite troubling revelation by @SomeoneElse that changeset
>> comments are
>> automatically republished by the third party private company Slack, I
>> would
>> appreciate if you could share your legal assessment of this situation.
>> More
>> specifically, what is the copyright status of changeset comments and
>> which OSMF
>> document or agreement covers changeset comments?
>>
>
> Can you be more specific? Where is the data being republished?
>
> Best,
> Clifford
> --
> @osm_washington
> www.snowandsnow.us
> OpenStreetMap: Maps with a human touch
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk
>
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [Talk-us] place=neighborhood on subdivisions?

[Paul Johnson]

On Tue, Sep 22, 2020 at 8:36 PM Mike N  wrote:

> On 9/22/2020 9:26 PM, Paul Johnson wrote:
> > The extra hamlet nodes are import remainders that haven't yet
> been
> > converted to landuse areas.   The general landuse zones for that area
> > have been identified, but do not exactly correspond to the named
> > subdivisions.   As I get a chance to survey, I divide the landuse
> into
> > subdivisions and convert the node to a named area for the
> subdivision.
> >
> >
> > Please don't expand these as landuse, please expand them as
> > place=neighborhood instead.  Landuse polygons should be congruent to the
> > actual land use.
>
> That's a good point: the subdivisions often contain one or more landuse
> basins, clusters of trees, etc.   I've been thinking of them as one big
> blob, but it seem correct on a more micromap level to mark them as
> place=, and identify the smaller landuse areas (which are sometimes all
> residential).
>

Exactly.  My rule of thumb is if you're thinking about putting a name on
it, and it's not a shopping center, apartment complex or similar large but
contiguous landuse, then landuse=* probably isn't what your polygon should
be.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] place=neighborhood on subdivisions?

[Mike N]

On 9/22/2020 9:26 PM, Paul Johnson wrote:

    The extra hamlet nodes are import remainders that haven't yet been
converted to landuse areas.   The general landuse zones for that area
have been identified, but do not exactly correspond to the named
subdivisions.   As I get a chance to survey, I divide the landuse into
subdivisions and convert the node to a named area for the subdivision.


Please don't expand these as landuse, please expand them as 
place=neighborhood instead.  Landuse polygons should be congruent to the 
actual land use.


That's a good point: the subdivisions often contain one or more landuse 
basins, clusters of trees, etc.   I've been thinking of them as one big 
blob, but it seem correct on a more micromap level to mark them as 
place=, and identify the smaller landuse areas (which are sometimes all 
residential).


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

Re: [Talk-us] place=neighborhood on subdivisions?

[Paul Johnson]

On Tue, Sep 22, 2020 at 8:20 PM Mike N  wrote:

> On 9/22/2020 8:56 PM, Karson Sommer wrote:
> >
> > Looking around the area of the edit, there is a lot of stuff from my
> > perspective that seems fishy. There are a bunch of place=hamlet nodes? I
> > certainly don't see anything that should be tagged as a hamlet, they all
> > look like place=neighborhood to me. Each of these nodes should be mapped
> > onto an explicit residential area.
>
>The extra hamlet nodes are import remainders that haven't yet been
> converted to landuse areas.   The general landuse zones for that area
> have been identified, but do not exactly correspond to the named
> subdivisions.   As I get a chance to survey, I divide the landuse into
> subdivisions and convert the node to a named area for the subdivision.
>

Please don't expand these as landuse, please expand them as
place=neighborhood instead.  Landuse polygons should be congruent to the
actual land use.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] place=neighborhood on subdivisions?

[Mike N]

On 9/22/2020 8:56 PM, Karson Sommer wrote:


Looking around the area of the edit, there is a lot of stuff from my 
perspective that seems fishy. There are a bunch of place=hamlet nodes? I 
certainly don't see anything that should be tagged as a hamlet, they all 
look like place=neighborhood to me. Each of these nodes should be mapped 
onto an explicit residential area.


  The extra hamlet nodes are import remainders that haven't yet been 
converted to landuse areas.   The general landuse zones for that area 
have been identified, but do not exactly correspond to the named 
subdivisions.   As I get a chance to survey, I divide the landuse into 
subdivisions and convert the node to a named area for the subdivision.


  I see one multipolygon from back in the day when I was still marking 
subdivision areas as hamlets when converting from a node to an area.


 This is all part of the normal OSM work in progress.



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

Re: [Talk-us] place=neighborhood on subdivisions?

[stevea]

I'm harmonious with Minh's comments in the changeset.

The place key, with value suburb, has quite specific meanings, I don't think 
these are those.  And as we don't or shouldn't be truly precise and especially 
not authoritative with "legal subdivisions," I think the "more informal" nature 
of OSM data entry around what a local (resident) might consider "a 
neighborhood" (especially as one distinct from place=neighbourhood. which also 
has quite specific meanings) and not necessarily one taggable with 
admin_level=10 (as it hasn't any administrative neighborhood council, extant, 
but rare in the USA) then yes, use landuse=residential (with a name=*) tag.  
That has worked for some time, it does work for now, and appears it will work 
into the future.

Read https://wiki.osm.org/wiki/Key:place (which will show this very likely 
shouldn't be used).
Read https://wiki.osm.org/wiki/United_States_admin_level (which will show this 
very likely shouldn't be used).
Read https://wiki.osm.org/wiki/Key:landuse.  It's a good match for "these" 
(roughly, "subdivisions"), especially with a name tag, since a bonus is the 
name tag renders nicely in Carto.  Carto rendering is not the reason to do it, 
simply a "nice to have, since it's done correctly, Carto rewards you with an 
appropriate rendering."  Carto does a pretty good job (maybe even always 
getting a bit better as time goes on) of rendering what you tag, when you tag 
appropriately.  Tag "appropriately" and help it out:  it will help you out with 
a pretty "blossom" of your tagging.  (Unless it doesn't, but then we're out at 
the hairy edge of OSM and Carto...another, bigger, topic).

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

Re: [Talk-us] place=neighborhood on subdivisions?

[Paul Johnson]

On Tue, Sep 22, 2020 at 7:14 PM Mike N  wrote:

> Thoughts on use of place=neighborhood for subdivisions?
> https://www.openstreetmap.org/changeset/91255294
>
>Note that there are many thousands already tagged this way (5000 plus
> in a section of the southeast alone).


 I'd consider a subdivision place=neighborhood and give it a boundary.  One
of the few examples where a boundary is cut and clear on the ground even.

landuse=* isn't the right thing for this, it's not interchangeable with
place=* or boundary=*...
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] place=neighborhood on subdivisions?

[Karson Sommer]

I agree with the way it was already mapped. Subdivisions should be mapped
as areas tagged with landuse=residential, place=neighborhood, and name=* if
it is named.

Looking around the area of the edit, there is a lot of stuff from my
perspective that seems fishy. There are a bunch of place=hamlet nodes? I
certainly don't see anything that should be tagged as a hamlet, they all
look like place=neighborhood to me. Each of these nodes should be mapped
onto an explicit residential area.

I'm not sure why the people in the changeset comments seem to think that a
subdivision != neighborhood. Per the OSM Wiki definition,

A *neighbourhood* is a named, geographically localised place. It may be an
area within a place =suburb
 or place
=quarter
 of a larger
settlement (such as a large place
=city
) or an area within a
smaller settlement (such as a place
=town
 or a place
=village
).

A subdivision just means a residential area with one developer. This means
all the houses will be in the same architectural style, same age, and can
be located using the subdivision name. This is the textbook definition of a
neighborhood.


On Tue, Sep 22, 2020 at 7:16 PM Mike N  wrote:

> Thoughts on use of place=neighborhood for subdivisions?
> https://www.openstreetmap.org/changeset/91255294
>
>Note that there are many thousands already tagged this way (5000 plus
> in a section of the southeast alone).
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] place=neighborhood on subdivisions?

[Joshua Carlson]

I’ve seen it used that way. I don’t see anything wrong with it, so long as it’s actually a named place that people would refer to, as opposed to a cadastral unit. If the subdivision has one of those signs at the entrance, or locals know what you mean when someone says they live in “Hickory Creek”, or whatever. It’s not as useful to know if it’s “HICKORY CREEK FIRST RESUB UNIT 1”. Also, I would create the area similarly to landuse=residential, which does not always correspond to a subdivision’s legal boundary. Around me, there are a number of subdivisions that technically own a large portion of open space at the back as an outlot, but outside of the county’s land records, there is no distinguishable feature from aerial imagery or on the ground that would indicate the woods/meadow/etc is “in” the subdivision. But that may just be me. From: Mike NSent: Tuesday, September 22, 2020 19:16To: talk-us@openstreetmap.orgSubject: [Talk-us] place=neighborhood on subdivisions? Thoughts on use of place=neighborhood for subdivisions? https://www.openstreetmap.org/changeset/91255294    Note that there are many thousands already tagged this way (5000 plus in a section of the southeast alone). ___Talk-us mailing listTalk-us@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-us 

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

Re: [OSM-legal-talk] Changeset Comments Copyright

[Clifford Snow]

On Tue, Sep 22, 2020 at 2:43 PM GITNE  wrote:

> Hello OSMF Legal Team,
>
> due to a quite troubling revelation by @SomeoneElse that changeset
> comments are
> automatically republished by the third party private company Slack, I would
> appreciate if you could share your legal assessment of this situation. More
> specifically, what is the copyright status of changeset comments and which
> OSMF
> document or agreement covers changeset comments?
>

Can you be more specific? Where is the data being republished?

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

[Talk-us] place=neighborhood on subdivisions?

[Mike N]

Thoughts on use of place=neighborhood for subdivisions? 
https://www.openstreetmap.org/changeset/91255294


  Note that there are many thousands already tagged this way (5000 plus 
in a section of the southeast alone).


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

Re: [Talk-pe] Eliminación de objetos y perdidas de etiquetas en Moyobamba por parte del usuario Dayen

[Omar Vega Ramos]

Hola

Por lo pronto en este conjunto de cambios 91320456 [0] ha continuado con
el mismo patrón de eliminar vías por la zona donde va a agregar
edificios y muros. Un parking lo ha eliminado para dibujar otro con la
misma geometría y las mismas etiquetas, la otra la ha eliminado y ha
agregado otra con las mismas etiquetas y otra geometría, perdiéndose en
ambos casos el historial.

Saludos

[0] https://www.openstreetmap.org/changeset/91320456

El 2020-09-22 16:42, Johnattan Rupire escribió:
> Muchas gracias Omar, espero que se anime a preguntar por aquí por lo
> que le pueda estar faltando para realizar mejor su mapeo.
> Voy a revisar sus conjuntos de cambios y le comentaré alguno.
> Saludos!
> 
> El 22 de septiembre de 2020 4:22:17 PM GMT-05:00, Omar Vega Ramos
>  escribió:
>>Hola
>>
>>El usuario ha respondido [0] sobre algunos nodos de transporte público
>>eliminados en el conjunto de cambios 91181524 [0] y un colegio en el
>>conjunto de cambios 91259402 [1], sobre el cual dice que ha cambiado de
>>lugar, pero no ha agregado el nuevo lugar. Sin embargo tampoco aclara
>>el
>>porque de la eliminación de las múltiples entidades públicas y de la
>>perdida del contornos y etiquetas en otros objetos. Indicándole también
>>que el patrón de mapeos hace pensar que elimina las vías solamente para
>>poder tener mayor visibilidad para dibujar los edificios y muros,
>>perdiéndose información sobre el contorno, etiquetas e historial de las
>>vías, ya que en algunos conjuntos de cambios incluso ha eliminado vías
>>agregando otras similares, con la misma geometría. Por otra parte
>>también parece de ignorar las solicitudes sobre el uso de buenos
>>conjuntos de cambios [2] que permitan a otros miembros de la comunidad
>>entender en que han consistido sus cambios, colocando solo el texto
>>"Moyobamaba", tambien le he indicado sobre reutilizar las vías para
>>mantener el historial de los objetos [3].
>>
>>Le he respondido en ese mismo conjunto de cambios [0] y lo he animado a
>>escribir por esta lista de correos para que otros miembros de la
>>comunidad puedan entender el porque de estas eliminaciones.
>>
>>Saludos
>>
>>[0] https://www.openstreetmap.org/changeset/91181524
>>[1] https://www.openstreetmap.org/changeset/91259402
>>[2]
>>https://wiki.openstreetmap.org/wiki/ES:Buenos_comentarios_en_conjuntos_de_cambios
>>[3] https://wiki.openstreetmap.org/wiki/ES:Mantener_el_historial
>>
>>El 2020-09-22 01:31, Omar Vega Ramos escribió:
>>> Hola
>>>
>>> Desde hace unos meses atrás el usuario Dayen ha estado ingresando
>>datos
>>> de edificios y barreras en la ciudad de Moyobamba. Sin embargo para
>>este
>>> propósito el usuario ha estado eliminando diferentes objetos
>>ingresados
>>> por otros usuarios. Aquí algunas de la ediciones:
>>>
>>> En el conjuntos de cambios 87256456 [0] elimina una vía con etiqueta
>>> resort, también retira una vía con water_works para dejar un nodo en
>>una
>>> de las oficinas.
>>> En el conjunto de cambios 87310986 [1] elimina la vía de un hospital
>>> para colocar edificios dentro del área.
>>> En el conjunto de cambios 87514685 [2] elimina la vía de un estadio
>>para
>>> colocar edificios.
>>> En el conjunto de cambios 87518421 [3] elimina la vía de una
>>> universidad, nodos de colegios y kindergarten para colocar edificios.
>>> En el conjunto de cambios 87611372 [4] elimina la vía de una empresa,
>>un
>>> nodo de comida rápida para añadir edificios.
>>> En el conjunto de cambios 87615816 [5] elimina la vía de un hospital
>>> para añadir edificios.
>>> En el conjunto de cambios 88108346 [6] elimina la vía de una iglesia
>>> para añadir edificios y un nodo como reemplazo de la iglesia.
>>> En el conjunto de cambios 88163037 [7] elimina un restaurante para
>>> añadir un edificio.
>>> En el conjunto de cambios 88189797 [8] elimina un parque.
>>> En el conjunto de cambios 88190610 [9] elimina un centro de
>>jardinería
>>> para añadir un nodo con menor cantidad de etiquetas.
>>> En los conjuntos de cambios 89538619 [10], 89542213 [11] y 89593832
>>[12]
>>> cambia parques a manzanas, elimina múltiples colegios y agrega
>>manzanas
>>> en su lugar.
>>> En el conjunto de cambios 90213228 [13] elimina un colegio para
>>añadir
>>> edificios.
>>> En el conjunto de cambios 9096 [14] elimina una oficina de
>>correos y
>>> un restaurante para añadir edificio.
>>> En el conjunto de cambios 90894888 [15] elimina un restaurante para
>>> añadir edificios.
>>> En el conjunto de cambios 91012797 [16] elimina vías de mercados para
>>> añadir edificios y un nodo de mercado.
>>> En el conjunto de cambios 91075777 [17] elimina vía de iglesias y
>>agrega
>>> edificios, ademas de un nodo que reemplaza a la iglesia.
>>> En el conjunto de cambios 91175629 [18] elimina una oficina de
>>correos,
>>> cambia vías a nodos, las cuales tiene menos etiquetas que las vías
>>> originales, perdiéndose información agregada por otros usuarios.
>>> En el conjunto de cambios 91181524 [19] elimina nodos de empresa de
>>> transporte 

[OSM-legal-talk] Changeset Comments Copyright

[GITNE]

Hello OSMF Legal Team,

due to a quite troubling revelation by @SomeoneElse that changeset comments are
automatically republished by the third party private company Slack, I would
appreciate if you could share your legal assessment of this situation. More
specifically, what is the copyright status of changeset comments and which OSMF
document or agreement covers changeset comments?

As far as I can tell no document covers changeset comments either explicitly nor
implicitly. The Contributor Terms state that “…contributing data and/or any
other content (collectively, “Contents”) to the geo-database of the
OpenStreetMap project (the “Project”)” is explicitly limited to contributions to
the geo-database (map database). As far as I can tell changeset comments are not
part of the OSM's geo-database. Changeset comments themselves do not contain any
geo-data, they merely reference a changeset. The changeset contains geo-data and
is what actually becomes part of the geo-database. Thus naturally changesets are
covered by the Contributor Terms but not changeset comments. Consequently, it
should be fair to assume that the copyright to changeset comments remains with
their respective authors. However, since changeset comments are apparently
neither explicitly nor implicitly covered by any agreement or license, it should
be also fair to assume that by the act of creating comments on OSM's website
commentators do grant copyright to the OSMF, though limited in scope. It is fair
to assume that the scope is limited to the production or quality assurance of
the map. I think that given this situation it should be very difficult to argue
that commentators implicitly grant copyright to any other party than the OSMF,
publish comments into the public domain, or for any extended purpose.

Anyhow, imho either way it would not be wise—today's more fashionable word here
would be “smart”—for the OSMF to grant changeset comment copyright to others.
There are many good reasons why this should not happen. Just for one, changeset
comments are not part OSMF's /product/, yet they are still publicly available
and thus enable full transparency. So, there is really no need for others to
reproduce them, especially for profit.

Regards
GITNE

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

Re: [Talk-pe] Eliminación de objetos y perdidas de etiquetas en Moyobamba por parte del usuario Dayen

[Johnattan Rupire]

Muchas gracias Omar, espero que se anime a preguntar por aquí por lo que le 
pueda estar faltando para realizar mejor su mapeo.
Voy a revisar sus conjuntos de cambios y le comentaré alguno.
Saludos!

El 22 de septiembre de 2020 4:22:17 PM GMT-05:00, Omar Vega Ramos 
 escribió:
>Hola
>
>El usuario ha respondido [0] sobre algunos nodos de transporte público
>eliminados en el conjunto de cambios 91181524 [0] y un colegio en el
>conjunto de cambios 91259402 [1], sobre el cual dice que ha cambiado de
>lugar, pero no ha agregado el nuevo lugar. Sin embargo tampoco aclara
>el
>porque de la eliminación de las múltiples entidades públicas y de la
>perdida del contornos y etiquetas en otros objetos. Indicándole también
>que el patrón de mapeos hace pensar que elimina las vías solamente para
>poder tener mayor visibilidad para dibujar los edificios y muros,
>perdiéndose información sobre el contorno, etiquetas e historial de las
>vías, ya que en algunos conjuntos de cambios incluso ha eliminado vías
>agregando otras similares, con la misma geometría. Por otra parte
>también parece de ignorar las solicitudes sobre el uso de buenos
>conjuntos de cambios [2] que permitan a otros miembros de la comunidad
>entender en que han consistido sus cambios, colocando solo el texto
>"Moyobamaba", tambien le he indicado sobre reutilizar las vías para
>mantener el historial de los objetos [3].
>
>Le he respondido en ese mismo conjunto de cambios [0] y lo he animado a
>escribir por esta lista de correos para que otros miembros de la
>comunidad puedan entender el porque de estas eliminaciones.
>
>Saludos 
>
>[0] https://www.openstreetmap.org/changeset/91181524
>[1] https://www.openstreetmap.org/changeset/91259402
>[2]
>https://wiki.openstreetmap.org/wiki/ES:Buenos_comentarios_en_conjuntos_de_cambios
>[3] https://wiki.openstreetmap.org/wiki/ES:Mantener_el_historial
>
>El 2020-09-22 01:31, Omar Vega Ramos escribió:
>> Hola
>> 
>> Desde hace unos meses atrás el usuario Dayen ha estado ingresando
>datos
>> de edificios y barreras en la ciudad de Moyobamba. Sin embargo para
>este
>> propósito el usuario ha estado eliminando diferentes objetos
>ingresados
>> por otros usuarios. Aquí algunas de la ediciones:
>> 
>> En el conjuntos de cambios 87256456 [0] elimina una vía con etiqueta
>> resort, también retira una vía con water_works para dejar un nodo en
>una
>> de las oficinas.
>> En el conjunto de cambios 87310986 [1] elimina la vía de un hospital
>> para colocar edificios dentro del área.
>> En el conjunto de cambios 87514685 [2] elimina la vía de un estadio
>para
>> colocar edificios.
>> En el conjunto de cambios 87518421 [3] elimina la vía de una
>> universidad, nodos de colegios y kindergarten para colocar edificios.
>> En el conjunto de cambios 87611372 [4] elimina la vía de una empresa,
>un
>> nodo de comida rápida para añadir edificios.
>> En el conjunto de cambios 87615816 [5] elimina la vía de un hospital
>> para añadir edificios.
>> En el conjunto de cambios 88108346 [6] elimina la vía de una iglesia
>> para añadir edificios y un nodo como reemplazo de la iglesia.
>> En el conjunto de cambios 88163037 [7] elimina un restaurante para
>> añadir un edificio.
>> En el conjunto de cambios 88189797 [8] elimina un parque.
>> En el conjunto de cambios 88190610 [9] elimina un centro de
>jardinería
>> para añadir un nodo con menor cantidad de etiquetas.
>> En los conjuntos de cambios 89538619 [10], 89542213 [11] y 89593832
>[12]
>> cambia parques a manzanas, elimina múltiples colegios y agrega
>manzanas
>> en su lugar.
>> En el conjunto de cambios 90213228 [13] elimina un colegio para
>añadir
>> edificios.
>> En el conjunto de cambios 9096 [14] elimina una oficina de
>correos y
>> un restaurante para añadir edificio.
>> En el conjunto de cambios 90894888 [15] elimina un restaurante para
>> añadir edificios.
>> En el conjunto de cambios 91012797 [16] elimina vías de mercados para
>> añadir edificios y un nodo de mercado.
>> En el conjunto de cambios 91075777 [17] elimina vía de iglesias y
>agrega
>> edificios, ademas de un nodo que reemplaza a la iglesia.
>> En el conjunto de cambios 91175629 [18] elimina una oficina de
>correos,
>> cambia vías a nodos, las cuales tiene menos etiquetas que las vías
>> originales, perdiéndose información agregada por otros usuarios.
>> En el conjunto de cambios 91181524 [19] elimina nodos de empresa de
>> transporte publico para añadir edificios.
>> En el conjunto de cambios 91258200 [20] elimina nodos de restaurante
>y
>> de una empresa de transporte publico.
>> En el conjunto de cambios 91259402 [21] elimina la vía de un colegio,
>> municipalidad y un bazar para añadir la municipalidad como un nodo y
>> vías de edificios con geometrías similares en su lugar, perdiéndose
>el
>> historial del objeto.
>> 
>> En múltiples ocasiones he recuperado objetos que existen en la zona,
>así
>> como etiquetas que fueron eliminadas al haber cambiado las vías por
>> nodos con menos etiquetas, que ha su vez causa la 

Re: [Talk-pe] Eliminación de objetos y perdidas de etiquetas en Moyobamba por parte del usuario Dayen

[Omar Vega Ramos]

Hola

El usuario ha respondido [0] sobre algunos nodos de transporte público
eliminados en el conjunto de cambios 91181524 [0] y un colegio en el
conjunto de cambios 91259402 [1], sobre el cual dice que ha cambiado de
lugar, pero no ha agregado el nuevo lugar. Sin embargo tampoco aclara el
porque de la eliminación de las múltiples entidades públicas y de la
perdida del contornos y etiquetas en otros objetos. Indicándole también
que el patrón de mapeos hace pensar que elimina las vías solamente para
poder tener mayor visibilidad para dibujar los edificios y muros,
perdiéndose información sobre el contorno, etiquetas e historial de las
vías, ya que en algunos conjuntos de cambios incluso ha eliminado vías
agregando otras similares, con la misma geometría. Por otra parte
también parece de ignorar las solicitudes sobre el uso de buenos
conjuntos de cambios [2] que permitan a otros miembros de la comunidad
entender en que han consistido sus cambios, colocando solo el texto
"Moyobamaba", tambien le he indicado sobre reutilizar las vías para
mantener el historial de los objetos [3].

Le he respondido en ese mismo conjunto de cambios [0] y lo he animado a
escribir por esta lista de correos para que otros miembros de la
comunidad puedan entender el porque de estas eliminaciones.

Saludos 

[0] https://www.openstreetmap.org/changeset/91181524
[1] https://www.openstreetmap.org/changeset/91259402
[2]
https://wiki.openstreetmap.org/wiki/ES:Buenos_comentarios_en_conjuntos_de_cambios
[3] https://wiki.openstreetmap.org/wiki/ES:Mantener_el_historial

El 2020-09-22 01:31, Omar Vega Ramos escribió:
> Hola
> 
> Desde hace unos meses atrás el usuario Dayen ha estado ingresando datos
> de edificios y barreras en la ciudad de Moyobamba. Sin embargo para este
> propósito el usuario ha estado eliminando diferentes objetos ingresados
> por otros usuarios. Aquí algunas de la ediciones:
> 
> En el conjuntos de cambios 87256456 [0] elimina una vía con etiqueta
> resort, también retira una vía con water_works para dejar un nodo en una
> de las oficinas.
> En el conjunto de cambios 87310986 [1] elimina la vía de un hospital
> para colocar edificios dentro del área.
> En el conjunto de cambios 87514685 [2] elimina la vía de un estadio para
> colocar edificios.
> En el conjunto de cambios 87518421 [3] elimina la vía de una
> universidad, nodos de colegios y kindergarten para colocar edificios.
> En el conjunto de cambios 87611372 [4] elimina la vía de una empresa, un
> nodo de comida rápida para añadir edificios.
> En el conjunto de cambios 87615816 [5] elimina la vía de un hospital
> para añadir edificios.
> En el conjunto de cambios 88108346 [6] elimina la vía de una iglesia
> para añadir edificios y un nodo como reemplazo de la iglesia.
> En el conjunto de cambios 88163037 [7] elimina un restaurante para
> añadir un edificio.
> En el conjunto de cambios 88189797 [8] elimina un parque.
> En el conjunto de cambios 88190610 [9] elimina un centro de jardinería
> para añadir un nodo con menor cantidad de etiquetas.
> En los conjuntos de cambios 89538619 [10], 89542213 [11] y 89593832 [12]
> cambia parques a manzanas, elimina múltiples colegios y agrega manzanas
> en su lugar.
> En el conjunto de cambios 90213228 [13] elimina un colegio para añadir
> edificios.
> En el conjunto de cambios 9096 [14] elimina una oficina de correos y
> un restaurante para añadir edificio.
> En el conjunto de cambios 90894888 [15] elimina un restaurante para
> añadir edificios.
> En el conjunto de cambios 91012797 [16] elimina vías de mercados para
> añadir edificios y un nodo de mercado.
> En el conjunto de cambios 91075777 [17] elimina vía de iglesias y agrega
> edificios, ademas de un nodo que reemplaza a la iglesia.
> En el conjunto de cambios 91175629 [18] elimina una oficina de correos,
> cambia vías a nodos, las cuales tiene menos etiquetas que las vías
> originales, perdiéndose información agregada por otros usuarios.
> En el conjunto de cambios 91181524 [19] elimina nodos de empresa de
> transporte publico para añadir edificios.
> En el conjunto de cambios 91258200 [20] elimina nodos de restaurante y
> de una empresa de transporte publico.
> En el conjunto de cambios 91259402 [21] elimina la vía de un colegio,
> municipalidad y un bazar para añadir la municipalidad como un nodo y
> vías de edificios con geometrías similares en su lugar, perdiéndose el
> historial del objeto.
> 
> En múltiples ocasiones he recuperado objetos que existen en la zona, así
> como etiquetas que fueron eliminadas al haber cambiado las vías por
> nodos con menos etiquetas, que ha su vez causa la perdida del contorno y
> el historial del objeto, incluso en casos donde borra una vía para
> añadir otra con similar geometría causando que se pierda el historial
> del objeto.
> 
> Por otra parte, el usuario en sus conjuntos de cambios tampoco indica el
> motivo de sus cambios, ya que la gran mayoría solamente contienen el
> texto "Moyobamba", sin embargo sus ediciones parecen 

Re: [Talk-us] United States Bicycle Route System ballot(s) pending AASHTO approval

[stevea]

I have added a one-line addition to our USBRS wiki suggesting that some aspect 
of Lifecycle_prefix (with a link to that wiki) include into USBRS route 
proposals something like "proposed:route=bicycle" in addition to 
state=proposed, while welcoming further suggestions and refinements.  Thanks, 
again, Elliott, for a great suggestion.

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

Re: [Talk-at] Gefahr durch Internet-Bergrouten

[Robert Grübler]

Marcus MERIGHI  schrieb am Sa. 19.09.2020 15:29

> ... ob diese unterschiede in den tags sac_scale 
> und trail_visibility darstellen (nix=keine unterscheidung)

In OSM ist die Schwierigkeitsbewertung mit sac_scale akzeptiert, aber:

Der Alpenverein Südtirol spricht sich GEGEN eine Schwierigkeitsbewertung von 
Wanderwegen aus [1, Seite 9] und beruft sich dabei auf einen einstimmigen 
Grundsatzbeschluss der CAA (1997, Chamonix)

Das Land  Tirol MACHT eine Schwierigkeitsbewertung der Wanderwege [2] und 
referenziert denselben Grundsatzbeschluss [2, Seite 5]

Kennt jemand die Motive für den Grundsatzbeschluss 1997 in Chamonix?

[1] 
http://media.alpenverein.it/crmpilot/Wege/Markierungsrichtlinien%20dt%20Web.pdf 
[2] 
https://www.tirol.gv.at/fileadmin/themen/sport/berg-und-ski/berg_und_ski/TirolerBergwegekonzept2018.pdf
 

LG Robert


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

Re: [Talk-us] United States Bicycle Route System ballot(s) pending AASHTO approval

[Kerry Irons]

Yes, for USBR 201 we essentially followed the ECGW.  This made for some 
less-than-direct segments, but that was what the locals wanted.  But that does 
not mean that the route shown on OSM Cycle is proposed USBR 201.  Only when you 
see the 201 tag on the map will this be the case.


Kerry

-Original Message-
From: stevea  
Sent: Tuesday, September 22, 2020 3:57 PM
To: Elliott Plack 
Cc: talk-us 
Subject: Re: [Talk-us] United States Bicycle Route System ballot(s) pending 
AASHTO approval

On Sep 22, 2020, at 12:33 PM, Elliott Plack  wrote:
> Great work getting these into the map already Steve! I work on the MDOT bike 
> team (as a GIS consultant) so it is great to see this on the map so quickly.

Thank you, Elliott; nice to see your reply!  I agree about "so quickly:"  I 
posted a request here and just a couple/few days later, an intrepid OSM 
volunteer had finished USBR 201 in Maryland before I could brew a cup of 
coffee!  Then, when it was suggested that the route become fully 
bi-directional, he quickly refined it to be so (just yesterday).  Wow!  (OSM 
has some great mappers!)

> A note about the *proposed* routes, they do appear in the OSM Cyclemap 
> already [1].
> [1] = 
> https://www.openstreetmap.org/?mlat=39.5798=-76.6054#map=15/39.57
> 98/-76.6054=C

I believe what is going on here is that East Coast Greenway (ECG, a 
"quasi-national" bicycle route not part of the USBRS, but sometimes, like here, 
sharing segments with it as USBR 201) is that OpenCycleMap (OCM) is in the 
process of redrawing the combined / shared segments of ECG + USBR 201 (in 
Maryland).  OCM can (and often does) take several days or even a week or two to 
re-render.  And, Andy Allan (OCM's author/maintainer) recently upgraded OCM to 
vector tiles with some newer rules for how specific tags (including and 
especially routes tagged state=proposed) are differently-rendered than as 
before (before vector tiles).  If I'm mistaken and somebody wants to correct me 
here, I welcome that, as I'm speculating a bit at what/how OCM is "currently 
rendering."  It's a bit like watching paint dry:  the colors can change a bit 
as it does.

> Instead of using the `state=proposed` tagging [2], you might consider putting 
> a lifecycle prefix [3] on the network tag so as to prevent data users from 
> integrating it blindly.
> [2] = 
> https://www.openstreetmap.org/relation/11654314#map=11/39.5964/-76.202
> 2=C [3] = https://wiki.openstreetmap.org/wiki/Lifecycle_prefix

The usage of state=proposed on bicycle routes is long (in my experience, going 
back to about 2010) and somewhat complex history, I've exchanged quite a bit 
(though not TOO frequent!) emails with Andy on this, he has been most helpful, 
especially with the switch to vector tiles earlier this year.  It is also quite 
deliberate, as state=proposed DOES render (in OCM as dashed, not solid) but 
does NOT render in Lonvia's waymarkedtrails bicycle renderer, providing a 
contrast between seeing the routes as proposed (and dashed) or not as all, as 
they are "not quite yet approved nor signed (yet)."  This contrast is 
documented in our USBRS wiki.  Additionally, a newer bicycle renderer (cyclosm) 
has emerged which also renders state=proposed.

I very much like the idea of Lifecycle_prefix in addition to state=proposed (I 
don't think it must be a choice between one and the other).  Using both tags 
(state and a lifecycle prefix) somewhat "standardizes" the concept of 
"proposed" in a wider OSM context, while continuing use of state=proposed (as 
it is supported in OCM), allowing the "dashing" of routes so tagged to continue 
in those renderers where the tag is applied and is supported.  We (OSM, ACA, a 
sponsor of USBRS, even AASHTO itself) have all participated in rather carefully 
crafting and or supporting this process and set of tags, which emerged in 2013. 
 I gave a talk at SOTM-US / Washington, DC about this in April, 2014 and we've 
been using this carefully-hammered-out consensus since.  Your suggestion to 
consider Lifecycle_prefix in addition is both welcome and excellent, imo.  
Thank you.

If anybody wishes to contribute a suggested strategy to include 
Lifecycle_prefix tagging in our USBRS wiki, I welcome that and also consider 
doing so myself.

What a great project (OSM) we have here, SteveA 
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


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

Re: [Talk-it] Webinar sulla cura di OSM

[Luca Delucchi]

Il mar 22 set 2020, 21:16 Andrea Musuruane  ha scritto:

> Non va neanche questo. Oltre a non sentire, non riesco neanche a scrivere
> in chat e a togliere il muto. Usare una istanza di jitsi?
>

Firefox sembra avere un problema, puoi usare chrorium/chrome

>
> Ciao,
>
> Andrea
>

Ciao
Luca

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

Re: [Talk-us] United States Bicycle Route System ballot(s) pending AASHTO approval

[stevea]

On Sep 22, 2020, at 12:33 PM, Elliott Plack  wrote:
> Great work getting these into the map already Steve! I work on the MDOT bike 
> team (as a GIS consultant) so it is great to see this on the map so quickly.

Thank you, Elliott; nice to see your reply!  I agree about "so quickly:"  I 
posted a request here and just a couple/few days later, an intrepid OSM 
volunteer had finished USBR 201 in Maryland before I could brew a cup of 
coffee!  Then, when it was suggested that the route become fully 
bi-directional, he quickly refined it to be so (just yesterday).  Wow!  (OSM 
has some great mappers!)

> A note about the *proposed* routes, they do appear in the OSM Cyclemap 
> already [1].
> [1] = 
> https://www.openstreetmap.org/?mlat=39.5798=-76.6054#map=15/39.5798/-76.6054=C

I believe what is going on here is that East Coast Greenway (ECG, a 
"quasi-national" bicycle route not part of the USBRS, but sometimes, like here, 
sharing segments with it as USBR 201) is that OpenCycleMap (OCM) is in the 
process of redrawing the combined / shared segments of ECG + USBR 201 (in 
Maryland).  OCM can (and often does) take several days or even a week or two to 
re-render.  And, Andy Allan (OCM's author/maintainer) recently upgraded OCM to 
vector tiles with some newer rules for how specific tags (including and 
especially routes tagged state=proposed) are differently-rendered than as 
before (before vector tiles).  If I'm mistaken and somebody wants to correct me 
here, I welcome that, as I'm speculating a bit at what/how OCM is "currently 
rendering."  It's a bit like watching paint dry:  the colors can change a bit 
as it does.

> Instead of using the `state=proposed` tagging [2], you might consider putting 
> a lifecycle prefix [3] on the network tag so as to prevent data users from 
> integrating it blindly.
> [2] = 
> https://www.openstreetmap.org/relation/11654314#map=11/39.5964/-76.2022=C
> [3] = https://wiki.openstreetmap.org/wiki/Lifecycle_prefix

The usage of state=proposed on bicycle routes is long (in my experience, going 
back to about 2010) and somewhat complex history, I've exchanged quite a bit 
(though not TOO frequent!) emails with Andy on this, he has been most helpful, 
especially with the switch to vector tiles earlier this year.  It is also quite 
deliberate, as state=proposed DOES render (in OCM as dashed, not solid) but 
does NOT render in Lonvia's waymarkedtrails bicycle renderer, providing a 
contrast between seeing the routes as proposed (and dashed) or not as all, as 
they are "not quite yet approved nor signed (yet)."  This contrast is 
documented in our USBRS wiki.  Additionally, a newer bicycle renderer (cyclosm) 
has emerged which also renders state=proposed.

I very much like the idea of Lifecycle_prefix in addition to state=proposed (I 
don't think it must be a choice between one and the other).  Using both tags 
(state and a lifecycle prefix) somewhat "standardizes" the concept of 
"proposed" in a wider OSM context, while continuing use of state=proposed (as 
it is supported in OCM), allowing the "dashing" of routes so tagged to continue 
in those renderers where the tag is applied and is supported.  We (OSM, ACA, a 
sponsor of USBRS, even AASHTO itself) have all participated in rather carefully 
crafting and or supporting this process and set of tags, which emerged in 2013. 
 I gave a talk at SOTM-US / Washington, DC about this in April, 2014 and we've 
been using this carefully-hammered-out consensus since.  Your suggestion to 
consider Lifecycle_prefix in addition is both welcome and excellent, imo.  
Thank you.

If anybody wishes to contribute a suggested strategy to include 
Lifecycle_prefix tagging in our USBRS wiki, I welcome that and also consider 
doing so myself.

What a great project (OSM) we have here,
SteveA
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-it] Webinar sulla cura di OSM

[Andrea Musuruane]

Non va neanche questo. Oltre a non sentire, non riesco neanche a scrivere
in chat e a togliere il muto. Usare una istanza di jitsi?

Ciao,

Andrea

Il mar 22 set 2020, 21:13 Matteo Zaffonato  ha scritto:

> Cambio di programma, siamo su:
> https://edumeet.imaa.cnr.it/curaosm
>
> Matteo
>
> On Tue, Sep 22, 2020 at 10:01 AM Cascafico Giovanni 
> wrote:
>
>> Per stasera, ore 21:
>>
>> Meeting Jitsi:
>> https://mm.rd.unidata.it/osmgarden
>>
>> Note condivise e verbale:
>> https://etherpad.wikimedia.org/p/osmgarden
>>
>>
>> Ho creato stamattina i due servizi sopra... spero non ci sia un timeout.
>>
>> Il 21/09/20, Luca Delucchi ha scritto:
>> > On Mon, 21 Sep 2020 at 09:50, Cascafico Giovanni 
>> > wrote:
>> >
>> >> Si, confermo domani martedì 22 alle 21.
>> >>
>> >> Qualcuno ha delle preferenze sul server jitsi?
>> >>
>> >
>> > io  solitamente utilizzo uno di https://iorestoacasa.work
>> >
>> >
>> >> Per chi ha già usato la piattaforma, qual'è il metodo più pratico per
>> >> verbalizzare?
>> >>
>> >
>> > non ho idea, di solito verbalizza uno dopo
>> >
>> > --
>> > ciao
>> > Luca
>> >
>> > www.lucadelu.org
>> >
>>
>> ___
>> 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

Re: [Talk-it] Webinar sulla cura di OSM

[Matteo Zaffonato]

Cambio di programma, siamo su:
https://edumeet.imaa.cnr.it/curaosm

Matteo

On Tue, Sep 22, 2020 at 10:01 AM Cascafico Giovanni 
wrote:

> Per stasera, ore 21:
>
> Meeting Jitsi:
> https://mm.rd.unidata.it/osmgarden
>
> Note condivise e verbale:
> https://etherpad.wikimedia.org/p/osmgarden
>
>
> Ho creato stamattina i due servizi sopra... spero non ci sia un timeout.
>
> Il 21/09/20, Luca Delucchi ha scritto:
> > On Mon, 21 Sep 2020 at 09:50, Cascafico Giovanni 
> > wrote:
> >
> >> Si, confermo domani martedì 22 alle 21.
> >>
> >> Qualcuno ha delle preferenze sul server jitsi?
> >>
> >
> > io  solitamente utilizzo uno di https://iorestoacasa.work
> >
> >
> >> Per chi ha già usato la piattaforma, qual'è il metodo più pratico per
> >> verbalizzare?
> >>
> >
> > non ho idea, di solito verbalizza uno dopo
> >
> > --
> > ciao
> > Luca
> >
> > www.lucadelu.org
> >
>
> ___
> 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-us] maps missing attribution on usnews.com

[Adam Franco]

I was just reading through the recent US News & World Report college
rankings and saw my OSM handiwork in their maps locating each school, but
without any attribution. Tiles look to be served from their own domain.

Example: https://www.usnews.com/best-colleges/middlebury-college-3691

   - Map in page screen-shot
   

   - Map detail screen-shot
   


Is this considered "Substantial Usage" and shall I follow the rest of the
steps noted in the wiki?
https://wiki.openstreetmap.org/wiki/Lacking_proper_attribution

Thanks for any feedback,
Adam
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] Numérote ta ville ou quelque chose comme ça

[Jacques Lavignotte]

Le 22/09/2020 à 16:38, Jacques Lavignotte a écrit :
> Bonjour,
>
> Je ne trouve pas ou j'ai rêvé ?

Je n'avais pas revé !

Merci Antonin :

https://twitter.com/AdresseDataGouv/status/1301864764205920257

et la totale :

https://adresse.data.gouv.fr/

 Merci, Jacques

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

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

[OSM-talk-fr] Numérote ta ville ou quelque chose comme ça

[Jacques Lavignotte]

Bonjour,

Je ne trouve pas ou j'ai rêvé ?

Un article qui relatait l'intérêt de contacter sa Mairie pour leur 
proposer une action collaborative et communale consistant à améliorer la 
numérotation de ses rues ?


Aidez-moi à le retouver...

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

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

[OSM-talk-ie] Poor Law Unions and Electoral Divisions (EDs or DEDs)

[Brian Hollinshead]

Poor Law Unions and Electoral Divisions (EDs or DEDs) v Townlands and Civil
Parishes

While the coverage for Townlands and Civil parishes is splendidly almost
nationwide, Sadly the same is not the case for Poor law Unions (PLUs) and
EDs. I have added several dozen PLUs in recent months, mostly up the west
coast using groups of existing EDs but have now run out of EDs,
particularly in the North East. To complete some of the PLUs I have added
about 20 EDs in Fermanagh and Armagh.

I wonder if there is any appetite among mappers to participate in a project
to fill in the remaining outstanding Eds. As an example in the Union of
Armagh there are eight Registrars Districts which are made up of about 27
Eds. Each ED can be composed of between ten and forty townlands.

The ‘Select dissolved members’ plugin, by John Kennedy in Kildare, for JOSM
very quickly allows the listed townlands to be downloaded and then
dissolves the internal boundaries leaving only the new complete external
boundary. Child’s play to use.

The EDs  and the Registrars Districts used for recording Births Marriages
and Deaths are of interest to historians and genealogists . If there is
interest I suggest a pilot project to complete Poor Law Union No. 4, Armagh.
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

[talk-cz] Zářijový mapathon v Praze 29.9. v 18:30

[Jana Bauerová]

Ahoj,
Jménem komunity dobrovolníků z Missing Maps Cz Sk vás zvu na mapathon v coworku 
Opero na Praze 1, kde budeme mapovat podle satelitních snímků pro Lékaře bez 
hranic - Médecins sans Frontières (MSF). Bude za týden v úterý 29.9. od 18:30 
do 20:30 s přednáškou o práci v terénu MSF logistika Zdeňka Müllera v 20hod.
Pokud byste se rádi přidali, tak si zajistěte místo na
https://www.eventbrite.co.uk/e/zarijovy-mapathon-v-praze-tickets-121159071043.
Počet účastníků je omezený a budeme se držet preventivních opatření jako nošení 
roušek uvnitř, desinfikování rukou, rozsazení, větrání/otevřené prostory, 
nekontaktní formy pozdravu atp.

Těším se na viděnou,
Jana Bauerová
Koordinátorka komunikace Missing Maps
Lékaři bez hranic
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[PanierAvide]

Comme pour l'instant les références ne ressortent plus du tout dans 
Osmose, j'imagine que le jour où on réactivera l'ajout de ref:FR:GeoDAE 
dans le signalement Osmose, tous les faux positifs seront à nouveau 
visibles. À noter qu'il faudra faire une passe de vérification sur les 
références déjà ajoutées dans OSM, vu la nature du bug côté GéoDAE je 
pense que tous les identifiants ajoutés ne seront plus valables.


Cordialement,

Adrien P.

Le 22/09/2020 à 10:37, osm.sanspourr...@spamgourmet.com a écrit :

Le 22/09/2020 à 10:07, PanierAvide - panierav...@riseup.net a écrit :


Dans les mises à jour récentes du flux, on a pu constater que
l'identifiant, documenté comme stable, ne l'était pas : les DAE sont
systématiquement renumérotés. (...)
Pour l'instant le mieux est de les marquer en faux positif sur Osmose
pour qu'ils disparaissent de la carte.


C'est une bonne solution si l'ancienne ref va réapparaître.

Si au contraire c'est la nouvelle qui va devenir stable, c'est un soucis.

Adrien, tu as confirmation que c'est l'ancien qui va revenir ?

Jean-Yvon



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


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

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[osm . sanspourriel]

Le 22/09/2020 à 10:07, PanierAvide - panierav...@riseup.net a écrit :


Dans les mises à jour récentes du flux, on a pu constater que
l'identifiant, documenté comme stable, ne l'était pas : les DAE sont
systématiquement renumérotés. (...)
Pour l'instant le mieux est de les marquer en faux positif sur Osmose
pour qu'ils disparaissent de la carte.


C'est une bonne solution si l'ancienne ref va réapparaître.

Si au contraire c'est la nouvelle qui va devenir stable, c'est un soucis.

Adrien, tu as confirmation que c'est l'ancien qui va revenir ?

Jean-Yvon



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

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[PanierAvide]

Bonjour,

Au départ, l'analyse Osmose reposait sur deux critères : la distance de 
rapprochement (100m) et la présence d'un identifiant "ref:FR:GeoDAE". 
Cet identifiant correspondait à la colonne "gid" de la base GéoDAE mis à 
disposition à travers le flux WMS du Ministère.


Dans les mises à jour récentes du flux, on a pu constater que 
l'identifiant, documenté comme stable, ne l'était pas : les DAE sont 
systématiquement renumérotés. C'est à priori un bug qui devrait être 
corrigé dans le futur. Pour l'instant les identifiants de GéoDAE ne sont 
donc pas utilisables. Du coup, je les ai retiré de l'analyse Osmose, 
pour ne garder que le critère de distance pour considérer qu'un DAE est 
intégré.


Sauf que la qualité variable des données de GéoDAE fait qu'on peut avoir 
des DAE à plus de 100m de leur position réelle sur le terrain. Ce sera 
ceux-ci qu'on retrouvera à ré-apparaître dans Osmose. Pour l'instant le 
mieux est de les marquer en faux positif sur Osmose pour qu'ils 
disparaissent de la carte.


À terme, la correction du bug d'identifiants de GéoDAE permettra une 
remise en place du critère de rapprochement sur les identifiants, et 
donc de ne plus avoir ces DAE trop loin qui reviennent.


Cordialement,

Adrien P.

Le 22/09/2020 à 09:54, Romain MEHUT a écrit :

Bonjour,

Petite question concernant Osmose. Après intégré des DAE, ils figurent 
toujours dans les proposition d'intégration dans Osmose.


Un exemple, https://www.openstreetmap.org/node/5754852748 mais 
toujours signalé ici 
http://osmose.openstreetmap.fr/fr/map/?#zoom=18=48.737443=5.985054=8370=1%2C2%2C3=merge=


Que manque-t-il pour qu'il disparaisse d'Osmose ?

Merci.

Romain

Le 04/08/2020 à 12:29, PanierAvide a écrit :

Bonjour à tous,

Et si on s'organisait un projet du mois en septembre, par exemple sur 
les défibrillateurs (DAE) ? :-)


https://wiki.openstreetmap.org/wiki/FR:Project_of_the_month/Defibrillateurs 



# Pourquoi les défibrillateurs ?

Il y a quelques semaines, la Direction Générale de la Santé a publié 
sa base GéoDAE (en cours de constitution), qui recense les 
défibrillateurs du pays. Un vaste chantier engagé depuis plusieurs 
mois, et qui commence à être visible par ces données. On y compte 
pour l'instant ~15000 défibrillateurs, dont 10% vérifiés par leur 
opérateur.


En parallèle, dans OSM sur la France, on compte ~6500 
défibrillateurs. Évidemment les deux bases ne se recoupent pas, 
certains DAE sont présents dans l'une et pas l'autre. En 2020, c'est 
quand même dommage. Alors si on s'y met en tant que communauté, on a 
possibilité d'obtenir une liste exhaustive sur le territoire de ces 
équipements !


# Quels sont les objectifs ?

L'objectif principal sera de recenser le plus possible de 
défibrillateur sur le terrain. On pourra ainsi s'aider de la base 
GéoDAE via Osmose et des bases ouvertes par certaines collectivités. 
Mais le gros du travail va consister à arpenter les établissements 
pour retrouver ces équipements. Dans la mesure du possible, on 
renseignera les attributs annexes (localisation, opérateur, niveau...).


# Comment aider à la préparation ?

D'ici le début du projet en septembre, il y a quelques tâches qui 
restent à réaliser, si vous voulez prendre part à l'organisation 
c'est l'occasion !


- Vérifier / compléter la documentation sur le wiki, notamment sur 
les réutilisations existantes de ces données


- Écrire un article pour annoncer le projet du mois sur le site OSM 
France pour publication fin août, de manière générale préparer la 
communication vers l'extérieur sur cette démarche


- Prendre contact avec les groupes locaux OSM, les collectivités 
locales, les assos de secouristes... Toute structure susceptible de 
mobiliser ses membres pour contribuer au projet du mois


Au plaisir de discuter avec vous sur ce projet :-)





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


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

Re: [Talk-it] Webinar sulla cura di OSM

[Cascafico Giovanni]

Per stasera, ore 21:

Meeting Jitsi:
https://mm.rd.unidata.it/osmgarden

Note condivise e verbale:
https://etherpad.wikimedia.org/p/osmgarden


Ho creato stamattina i due servizi sopra... spero non ci sia un timeout.

Il 21/09/20, Luca Delucchi ha scritto:
> On Mon, 21 Sep 2020 at 09:50, Cascafico Giovanni 
> wrote:
>
>> Si, confermo domani martedì 22 alle 21.
>>
>> Qualcuno ha delle preferenze sul server jitsi?
>>
>
> io  solitamente utilizzo uno di https://iorestoacasa.work
>
>
>> Per chi ha già usato la piattaforma, qual'è il metodo più pratico per
>> verbalizzare?
>>
>
> non ho idea, di solito verbalizza uno dopo
>
> --
> ciao
> Luca
>
> www.lucadelu.org
>

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

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[Romain MEHUT]

Bonjour,

Petite question concernant Osmose. Après intégré des DAE, ils figurent 
toujours dans les proposition d'intégration dans Osmose.


Un exemple, https://www.openstreetmap.org/node/5754852748 mais toujours 
signalé ici 
http://osmose.openstreetmap.fr/fr/map/?#zoom=18=48.737443=5.985054=8370=1%2C2%2C3=merge=


Que manque-t-il pour qu'il disparaisse d'Osmose ?

Merci.

Romain

Le 04/08/2020 à 12:29, PanierAvide a écrit :

Bonjour à tous,

Et si on s'organisait un projet du mois en septembre, par exemple sur 
les défibrillateurs (DAE) ? :-)


https://wiki.openstreetmap.org/wiki/FR:Project_of_the_month/Defibrillateurs 



# Pourquoi les défibrillateurs ?

Il y a quelques semaines, la Direction Générale de la Santé a publié 
sa base GéoDAE (en cours de constitution), qui recense les 
défibrillateurs du pays. Un vaste chantier engagé depuis plusieurs 
mois, et qui commence à être visible par ces données. On y compte pour 
l'instant ~15000 défibrillateurs, dont 10% vérifiés par leur opérateur.


En parallèle, dans OSM sur la France, on compte ~6500 défibrillateurs. 
Évidemment les deux bases ne se recoupent pas, certains DAE sont 
présents dans l'une et pas l'autre. En 2020, c'est quand même dommage. 
Alors si on s'y met en tant que communauté, on a possibilité d'obtenir 
une liste exhaustive sur le territoire de ces équipements !


# Quels sont les objectifs ?

L'objectif principal sera de recenser le plus possible de 
défibrillateur sur le terrain. On pourra ainsi s'aider de la base 
GéoDAE via Osmose et des bases ouvertes par certaines collectivités. 
Mais le gros du travail va consister à arpenter les établissements 
pour retrouver ces équipements. Dans la mesure du possible, on 
renseignera les attributs annexes (localisation, opérateur, niveau...).


# Comment aider à la préparation ?

D'ici le début du projet en septembre, il y a quelques tâches qui 
restent à réaliser, si vous voulez prendre part à l'organisation c'est 
l'occasion !


- Vérifier / compléter la documentation sur le wiki, notamment sur les 
réutilisations existantes de ces données


- Écrire un article pour annoncer le projet du mois sur le site OSM 
France pour publication fin août, de manière générale préparer la 
communication vers l'extérieur sur cette démarche


- Prendre contact avec les groupes locaux OSM, les collectivités 
locales, les assos de secouristes... Toute structure susceptible de 
mobiliser ses membres pour contribuer au projet du mois


Au plaisir de discuter avec vous sur ce projet :-)





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

[Talk-pe] Eliminación de objetos y perdidas de etiquetas en Moyobamba por parte del usuario Dayen

[Omar Vega Ramos]

Hola

Desde hace unos meses atrás el usuario Dayen ha estado ingresando datos
de edificios y barreras en la ciudad de Moyobamba. Sin embargo para este
propósito el usuario ha estado eliminando diferentes objetos ingresados
por otros usuarios. Aquí algunas de la ediciones:

En el conjuntos de cambios 87256456 [0] elimina una vía con etiqueta
resort, también retira una vía con water_works para dejar un nodo en una
de las oficinas.
En el conjunto de cambios 87310986 [1] elimina la vía de un hospital
para colocar edificios dentro del área.
En el conjunto de cambios 87514685 [2] elimina la vía de un estadio para
colocar edificios.
En el conjunto de cambios 87518421 [3] elimina la vía de una
universidad, nodos de colegios y kindergarten para colocar edificios.
En el conjunto de cambios 87611372 [4] elimina la vía de una empresa, un
nodo de comida rápida para añadir edificios.
En el conjunto de cambios 87615816 [5] elimina la vía de un hospital
para añadir edificios.
En el conjunto de cambios 88108346 [6] elimina la vía de una iglesia
para añadir edificios y un nodo como reemplazo de la iglesia.
En el conjunto de cambios 88163037 [7] elimina un restaurante para
añadir un edificio.
En el conjunto de cambios 88189797 [8] elimina un parque.
En el conjunto de cambios 88190610 [9] elimina un centro de jardinería
para añadir un nodo con menor cantidad de etiquetas.
En los conjuntos de cambios 89538619 [10], 89542213 [11] y 89593832 [12]
cambia parques a manzanas, elimina múltiples colegios y agrega manzanas
en su lugar.
En el conjunto de cambios 90213228 [13] elimina un colegio para añadir
edificios.
En el conjunto de cambios 9096 [14] elimina una oficina de correos y
un restaurante para añadir edificio.
En el conjunto de cambios 90894888 [15] elimina un restaurante para
añadir edificios.
En el conjunto de cambios 91012797 [16] elimina vías de mercados para
añadir edificios y un nodo de mercado.
En el conjunto de cambios 91075777 [17] elimina vía de iglesias y agrega
edificios, ademas de un nodo que reemplaza a la iglesia.
En el conjunto de cambios 91175629 [18] elimina una oficina de correos,
cambia vías a nodos, las cuales tiene menos etiquetas que las vías
originales, perdiéndose información agregada por otros usuarios.
En el conjunto de cambios 91181524 [19] elimina nodos de empresa de
transporte publico para añadir edificios.
En el conjunto de cambios 91258200 [20] elimina nodos de restaurante y
de una empresa de transporte publico.
En el conjunto de cambios 91259402 [21] elimina la vía de un colegio,
municipalidad y un bazar para añadir la municipalidad como un nodo y
vías de edificios con geometrías similares en su lugar, perdiéndose el
historial del objeto.

En múltiples ocasiones he recuperado objetos que existen en la zona, así
como etiquetas que fueron eliminadas al haber cambiado las vías por
nodos con menos etiquetas, que ha su vez causa la perdida del contorno y
el historial del objeto, incluso en casos donde borra una vía para
añadir otra con similar geometría causando que se pierda el historial
del objeto.

Por otra parte, el usuario en sus conjuntos de cambios tampoco indica el
motivo de sus cambios, ya que la gran mayoría solamente contienen el
texto "Moyobamba", sin embargo sus ediciones parecen consistir en
agregar edificios y muros (posiblemente como algún trabajo de catastro)
y dan a pensar que la eliminación la realiza con la finalidad de poder
visualizar el fondo para dibujar los edificios.

Anteriormente le he escrito en algunos de sus conjuntos de cambios y
también le he invitado a realizar preguntas en el canal de telegram o el
lista de correos, pero el nunca ha respondido a los mensajes y ha
continuado eliminando objetos y etiquetas sin justificación, motivo por
el cual dejo este mensaje en la lista como constancia para realizar la
denuncia al usuario.

Saludos
[0] https://www.openstreetmap.org/changeset/87256456
[1] https://www.openstreetmap.org/changeset/87310986
[2] https://www.openstreetmap.org/changeset/87514685
[3] https://www.openstreetmap.org/changeset/87518421
[4] https://www.openstreetmap.org/changeset/87611372
[5] https://www.openstreetmap.org/changeset/87615816
[6] https://www.openstreetmap.org/changeset/88108346
[7] https://www.openstreetmap.org/changeset/88163037
[8] https://www.openstreetmap.org/changeset/88189797
[9] https://www.openstreetmap.org/changeset/88190610
[10] https://www.openstreetmap.org/changeset/89538619
[11] https://www.openstreetmap.org/changeset/89542213
[12] https://www.openstreetmap.org/changeset/89593832
[13] https://www.openstreetmap.org/changeset/90213228
[14] https://www.openstreetmap.org/changeset/9096
[15] https://www.openstreetmap.org/changeset/90894888
[16] https://www.openstreetmap.org/changeset/91012797
[17] https://www.openstreetmap.org/changeset/91075777
[18] https://www.openstreetmap.org/changeset/91175629
[19] https://www.openstreetmap.org/changeset/91181524
[20] https://www.openstreetmap.org/changeset/91258200
[21] 

Re: [Talk-GB] GIS Support Officer

[Dzidek23]

Again, maybe this time the link will show :)

Hello,

Came across this advert, maybe someone will be interested:
GIS Support Officer for Forestry Commission England

https://www.civilservicejobs.service.gov.uk/csr/jobs.cgi?jcode=1687990

This looks like a job between customer services, project management and GIS 
management with some learning opportunities.
Temp role but home working available :)

Cheerio!
dzidek23

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