Re: [OSM-talk] [Tagging] How to put a name tag on an area with more than one type?

[Joseph Eisenberg]

Re:  "why the OSM Foundation has a small budget and can't afford to hire
more than a cursory staff for the most critical needs"

This conversation was on the Tagging list, but I'm responding here to keep
on-topic.

It is worth mentioning that the small size of the OSMF organisation and
budget is considered a positive choice, rather than a handicap, by many
mappers who want OpenStreetMap to stay a volunteer-run, open, independent
community.

OpenStreetMap runs mostly based on volunteer mapper time, plus some
important volunteer time to provide services like functioning data servers,
geocoding and routing apps, and renderings. Only a small amount of money is
needed to keep everything running, and funding from just a part of the
mapper and database user community has been enough for this in the past.

In contrast, Wikimedia has a huge budget and a big organisation, but all
the control and decision-making is done by a small group. The large
expenses require extensive fundraising activities.

Some mappers and perhaps some on the current OSMF board would like to see
lots more funding to make it possible to do things like have more map
styles available, improved editing applications, faster servers, etc. - but
more funding means more fundraising and a bigger organisation and so on.
Once you start that, it's hard to cut off the funding, so there's a big
risk of fundraising suddenly drops off due to a recession or changes in
corporate priorities.

The current "do-ocracy" has disadvantages too, because it tends to
prioritize the interests of people who have the ability to do things on
computers:

Re: "when you speak of "OSM", you are not speaking to some big corporate
entity with a glass lobby, a receptionist, and someone to answer the phone
-- you are speaking to a loose tribe of individual volunteers that are
collaborating on a free map of the world."

And it's that way due to choices that this community has made over time. It
could be different, and might change in the future, based on the choices we
all make.

Personally I see benefits to both models, but the risks are much bigger on
one side.

-- Joseph Eisenberg

On Mon, Dec 14, 2020 at 2:44 PM Brian M. Sperlongano 
wrote:

> I agree with Mateusz that the wiki IS the project's standard document for
> the meaning of tagging (from the perspective of data consumers) and how to
> tag (from the perspective of mappers).  Note that both perspectives are
> important.  But to address the specific point, there is no standard
> document for renderer implementers, because there is no such thing as a
> standard renderer implementation.  A renderer (something that turns data
> into a map) is just one of very many ways to use and visualize geospatial
> data.
>
> I know you did not intend to criticize the volunteers that make this
> project happen, but consider that when you dismiss the wiki as "no
> documentation", it can be interpreted as dismissing the hard work of
> countless people that volunteered their time to develop (and translate!) a
> large and complex documentation base.  Most software developers find
> documentation to be a chore and the last thing they deal with.  That is why
> as someone who has the skills, time, and interest to contribute, I've
> expended considerable effort improving the wiki's tagging documentation,
> and when I've found gaps or problems, I've worked to draft and advance
> proposals to address the deficiencies.  I saw a need and began filling it,
> and my contributions to that documentation are something I am proud of.
>
> For a project that provides its only product for free, it should be
> obvious why the OSM Foundation has a small budget and can't afford to hire
> more than a cursory staff for the most critical needs.  Consider changing
> your perspective to "what am I able to contribute to make this project
> stronger?" rather than "here are the things that are wrong".
>
> As the author of a product that consumes OSM data, I am grateful to all of
> the programmers, mappers, and technologists that have built the various
> pieces of this ecosystem without which my product wouldn't exist.  It would
> be awfully presumptuous of me to complain that this thing provided to me
> entirely for free is in some way lacking, and I'm glad I am able to "give
> back" in this small way.
>
> This is just a gentle reminder that when you speak of "OSM", you are not
> speaking to some big corporate entity with a glass lobby, a receptionist,
> and someone to answer the phone -- you are speaking to a loose tribe of
> individual volunteers that are collaborating on a free map of the world.
>
> On Mon, Dec 14, 2020 at 4:15 PM Mateusz Konieczny via Tagging <
> tagg...@openstreetmap.org> wrote:
>
>>
>>
>>
>> Dec 14,

Re: [OSM-talk] Please review "Community attribution advice” wiki page

[Joseph Eisenberg]

The text of the first section previously ended with this sentence:

"To what extent you might practically get away with lesser attribution -
either legally or socially - is outside the scope of this document."

Probably such a sentence is acceptable in some cultures, but it sounds odd
in the Anglo-American legal context so I removed it.

However, perhaps there is a more polite way to say the same sort of thing,
without seeming to invite "getting away with it?"

-- Joseph Eisenberg

On Sat, Dec 5, 2020 at 12:36 AM Mateusz Konieczny via talk <
talk@openstreetmap.org> wrote:

> One thing that is missing to me is explicit mention that it is not
> overriding ODBL or related laws and is not adding any legal
> requirements.
>
> If someone follows ODBL license or is in situation where following license
> is not needed for some reason, they can legally do this.
>
> Maybe also mention that it is may be recommending more attribution than
> bare minimum that is required by ODBL, so it is a safe solution that should
> be also fine for any typical[1] project that is not hostile to OSM?
>
> [1] "typical" - especially for very small objects things gets trickier,
> if you are making some special purpose map (tactile map for blind)
> then attribution also needs to be adapted, if map is going to be used
> in place where English is not understood in general you will definitely
> need to translate attribution etc etc.
>
> https://wiki.openstreetmap.org/wiki/Draft_Attribution_Guideline claim
> that smartphone has not enough space for attribution is clearly untrue.
> But if you show OSM map on screen of size 1cm x 1 cm or similarly tiny
> physical object then alternative attribution methods - that still comply
> with
> ODBL - may be preferable.
>
> Dec 4, 2020, 21:41 by joseph.eisenb...@gmail.com:
>
> I appreciate the wik page "Community attribution advice" which was made
> by another community member. It seems to give good advice about how
> database users can comply with the attribution guidelines in a way that
> everybody* in this community can support.
>
> Please review the page and make any comments for improvement if needed:
>
> https://wiki.openstreetmap.org/wiki/Community_attribution_advice
>
> -- Joseph Eisenberg
>
> (*Note that "everybody" does not include the interests of corporations,
> which are not persons, but rather the interests of individual mappers and
> database users)
>
>
> ___
> 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] Please review "Community attribution advice” wiki page

[Joseph Eisenberg]

[This is the current text:]

This document is an attempt to summarize the expectations the OpenStreetMap
mapper community has for OSM data users regarding the attribution required
by the OpenStreetMap license.

In line with the general culture of OpenStreetMap it does not try to
provide step by step instructions on how to attribute but instead gives
advice on how the community views attribution and allows data users to meet
these expectations under their own responsibility.

Views within the OpenStreetMap mapper community on what kind of attribution
is or should be necessary vary slightly.  This advice in meant to describe
the consensus position in the sense that attribution designed based on this
advice will find a broad consensus among mappers to be acceptable.

== Why we require attribution ==

OpenStreetMap data is produced and maintained primarily by volunteer
mappers.  Data users do not need to provide any financial or other form of
remuneration to mappers for using their work - except attribution.
Attribution of use of OpenStreetMap data is the acknowledgement you need to
give to the mappers for the work they provide, which you are otherwise free
to use.  By doing so you express your respect and appreciation of the work
of millions of OpenStreetMap contributors that they allow you to freely
use, and help new volunteer mappers join the community for the benefit of
all database users. If your users do not know that OpenStreetMap is the
source of your data, they will not be able to fix mistakes and improve the
quality of the database. Not all OpenStreetMap mappers individually make
their contribution contingent on data users providing attribution but we
all expect this attribution to be provided by all data users as the
collective position of the whole mapper community based on which we have
chosen the license for our data.

== What we mean by attribution ==

What we understand attribution to mean is formally stated in [
https://opendatacommons.org/licenses/odbl/1-0/ section 4.3 of the ODbL]:

*"However, if you Publicly Use a Produced Work, You must include a notice
associated with the Produced Work reasonably calculated to make any Person
that uses, views, accesses, interacts with, or is otherwise exposed to the
Produced Work aware that Content was obtained from the Database, Derivative
Database, or the Database as part of a Collective Database, and that it is
available under this License."*

What we mean by this is that the criterion for a valid attribution is if it
effectively makes the user aware that OpenStreetMap data licensed under the
ODbL is used.  In case of an interactive map the widely used form of
attribution shown in one of the corners of the map can fulfill this
requirement when displayed at least in a size and prominence comparable to
other content displayed on the screen.  But it can also fail to do so if
displayed right next to a blinking ad catching all the user's attention,
for example.  It is the responsibility of those who publicly use
OpenStreetMap data to ensure the attribution fulfills its purpose and makes
the user aware of the provenience of the data.

You need to actively communicate this information to the user to meet these
requirements.  Merely making it available to users who are actively seeking
this information is not enough.

While we require you to attribute use of OpenStreetMap data we also want
you to only attribute OpenStreetMap for data which comes from our database
and not for any other geodata you might use in addition.  Therefore you
should be specific about what elements of your map or other work are based
on OpenStreetMap data in your attribution.

=== Interactive maps ===

In interactive applications of OpenStreetMap data, such as interactive
maps, it is accepted among mappers if the information about the nature of
the OpenStreetMap data license is provided through a link in contexts where
links are a generally expected method to provide more detailed
information.  The condition for this is that the medium of display allows
showing the information behind the link in a form readable for the user.
This condition needs to be considered in particular for applications that
are likely to be used offline.

The traditional form of attribution text in interactive online applications
is "© [https://www.openstreetmap.org/copyright OpenStreetMap contributors]"
with a link to https://www.openstreetmap.org/copyright.  This emphasizes
the above mentioned purpose of the attribution acknowledging the work of
the mappers.  The shortened "© OpenStreetMap" is typically also accepted
though some mappers prefer the longer and more specific version.

Note making the user aware does not require continuously nagging them about
it.  In a single user viewing situation it is perfectly all right - and in
some cases even desirable - to allow the user to hide the attribution after
seeing it. However, the attribution should not be automatically hidden
without action by the user


=== 

[OSM-talk] Please review "Community attribution advice” wiki page

[Joseph Eisenberg]

I appreciate the wik page "Community attribution advice" which was made by
another community member. It seems to give good advice about how database
users can comply with the attribution guidelines in a way that everybody*
in this community can support.

Please review the page and make any comments for improvement if needed:

https://wiki.openstreetmap.org/wiki/Community_attribution_advice

-- Joseph Eisenberg

(*Note that "everybody" does not include the interests of corporations,
which are not persons, but rather the interests of individual mappers and
database users)
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Updating of land/water polygons (based on natural=coastline) is too slow and unreliable

[Joseph Eisenberg]

I just found out that mappers in the east coast of the USA have been
converting coastal bays and tidal channels to natural=water areas because
they don't like how long it takes to get updated land/water polygons based
on the natural=coastline ways.

See the comments on this changeset, where Pamlico Sound (a large area of
water at the edge of the Atlantic Ocean, inside of a line of barrier
islands - comparable to the Waddenzee in the Netherlands) was changed to a
natural=water polygon with the natural=coastline removed.

"That was the reason we started removing the smaller estuaries from the
coastline, so edits to them would show up on the map in a timely fashion. "

Unfortunately to get faster re-rendering times, mappers are mis-tagging
these areas which should be outside of the coastline.

Is there any way we can improve the process of checking and updating the
water and land polygons, currently available on
https://osmdata.openstreetmap.de - so that mistakes do not lead to
multi-week waits for new polygons? Right now the last update was 11/11/2020
- ten days ago.

Is there any way of getting updates more often than once a day in the
best-case scenario when nothing is broken?

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

Re: [OSM-talk] reddit AMA with some OSMF Board members. 15:00Z 9 Nov

[Joseph Eisenberg]

Reddit is entirely blocked by all ISPs in Indonesia due to government
policy, so I am not able to participate in any discussions on that website
while I am living there.

- Joseph Eisenberg

On Thu, Oct 29, 2020 at 12:39 PM Rory McCann  wrote:

> Hello OSMers,
>
> Some of us on the OSM Foundation Board have agreed to do an AMA (Ask Me
> Anything) on the reddit forum for OpenStreetMap (aka “the r/openstreetmap
> subreddit”) starting on 15:00 UTC 9th November. It's an oppertunity to ask
> us some questions. Be gentle. 
>
> More details:
> https://www.reddit.com/r/openstreetmap/comments/jk73ez/annoucement_ama_with_osmf_board_members_on_9th_of/
>
> Event date/time in your timezone:
> https://www.timeanddate.com/worldclock/fixedtime.html?msg=Reddit+AMA+with+OSMF+board+members=20201109T15=1440=23=55
>
> Event Countdown:
> https://www.timeanddate.com/countdown/generic?p0=1440=20201109T15=Reddit%20AMA%20with%20OSMF%20board%20members
>
> Background https://en.wikipedia.org/wiki/R/IAmA
>
> See you there. 
>
> --
> Rory
>
> ___
> 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] Idea for improving mapping system

[Joseph Eisenberg]

Would you mind describing the proposed system here, in a concise form?

On Sat, Oct 17, 2020 at 7:36 PM TheAdventurer64 <
little.banana.p...@gmail.com> wrote:

> Hello everyone,
>
> A user and I were talking about implementing a system for better mapping,
> as described here:
> https://osmus.slack.com/archives/C029HV951/p1602968516431900
> This addition would have many benefits, including:
> * More mapping. We have tons of new mappers each day, as well as a great
> editor for them. However, many of these new mappers leave after just a few
> edits. Examples:
> https://www.openstreetmap.org/user/lukastheg03
> https://www.openstreetmap.org/user/Th3Roomi3
> ___
> 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] Reference numbers to use for hiking trail route relations

[Joseph Eisenberg]

Many of the old "pack trail" labeled features near my home-town are now
overgrown and barely usable. I would be skeptical about the utility of this
tag - mappers will need to survey the trail in person before suggesting
that it is currently suitable for horse, mules or other pack animals.

-Joseph Eisenberg

On Thu, Oct 15, 2020 at 10:02 AM stevea  wrote:

> brad  wrote
> > I think I've seen old usgs topo maps, or perhaps FS maps with trails
> labeled as pack trails.   Not quite sure what it means, probably nothing
> anymore.   Perhaps the OSM person just used the info from the old map.
>
> A "pack trail" is suitable for pack animals, such as donkeys or horses for
> carrying "in" supplies, building materials or hauling "out" garbage, ore
> waste or the like.  It is more substantial than a "single-track" trail for
> a bipedal human, but may or may not be suitable for an off-road vehicle
> like an off-road motorcycle, all-terrain-vehicle / four-runner or other
> high-clearance, two-axle vehicle.  It is a common phrase seen on maps of
> the 19th and 20th centuries, but has fallen somewhat out of favor, though
> is still seen and used.
>
> 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

[OSM-talk] OSM ↔ Wikidata - new tool encouraging automated / mechanical addition of wikidata tags

[Joseph Eisenberg]

https://wiki.openstreetmap.org/wiki/OSM_↔_Wikidata

According to the new wiki entry, OSM ↔ Wikidata is a tool that is supposed
to automatically find all wikidata entries for OpenStreetMap features in a
certain area, and make it easy to add the tags semi-automatically.

This seems like it will invite violations of the Automated Edits policy (
https://wiki.openstreetmap.org/wiki/Automated_edits)

"OSM ↔ Wikidata (osm-wikidata-link) is a web based tool that can be used to
semi-automatically add the Wikidata tag to an OpenStreetMap object. It is
developed by  Edward Betts (Edward) (and others github contributors) in
Python and web technologies (HTML/CSS/JS)."

"This tool displays results in tabs:

   1. Match candidates: display the potential OSM objects matching Wikidata
   item
  - This is the main tab. It allows user to match and add wikidata
  <https://wiki.openstreetmap.org/wiki/Key:wikidata>=* tags to OSM
  objects
   2. Already tagged: display the OSM object and his wikidata
   <https://wiki.openstreetmap.org/wiki/Key:wikidata>=* key
   3. No match: display Wikidata item without match in OSM
  - This tab allows user to edit OSM and add the wikidata
  <https://wiki.openstreetmap.org/wiki/Key:wikidata>=* tag manually
   4. Wikidata query: display the Wikidata SPARQL query."


What should we ask the developers to do so that this tool won't be
encouraging every to violate the Automated Edits policy?

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

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] Unintentional improvements in OSM data influencing / improving other databases

[Joseph Eisenberg]

RE: "Many government and agency data sources are in conflict with each
other over the same information; OSM can serve to provide "resolved"
versions that are confirmed with ground observation where required."

Similar thoughts have been expressed previously in this thread.

But if we are talking about legal parcel boundaries or legal protected area
boundaries, or administrative limits, then it's not at all possible for
OpenStreetMap users to resolve these conflicts in our database alone.

What needs to happen is bringing this information back to the local
government and asking them to correct the data and provide an
authoritative, public-domain source for everyone to use.

It's no good if OpenStreetMap has a more "accurate" boundary line which
follows a physical feature like a ridgeline, if the legal definition is
different. Determining this might require lawyers getting involved.

Now certainly OpenStreetMap data, which can include features like
ridgelines, waterways, roads and paths, which are often used to determine
historic land ownership boundaries, can be useful in determining if
existing databases are accurate and precise. But unless those outside
databases are corrected, our data will be inaccurate as well, when it comes
to legal issues like boundaries.

- Joseph Eisenberg

On Wed, Sep 2, 2020 at 11:39 AM Bradley White 
wrote:

> I echo this sentiment exactly as having taken place in California and in
>> my experiences with OSM.  This is most certainly a longer-term endeavor
>> (over several, even many years), but improvements in alignments between
>> data components which have been entered into OSM from my County GIS,
>> GreenInfo.org's publishing its "CPAD" (California Protected Area Database,
>> published semi-annually, see our wiki) and other sources HAVE INDEED
>> resulted in data improvements:  OSM influences CPAD, resulting in data
>> improvements, CPAD influenced County GIS data, resulting in data
>> improvements, later versions of these (County GIS and CPAD) data influenced
>> OSM all over again, resulting in data improvements...and upward, upward and
>> upward the spiral of more accurate, better-aligning data goes:  both
>> private and public.  OSM gets the results, so do others.  Win-win.  Taking
>> OSM out of the equation by asserting "these data don't belong in OSM" stops
>> this improvement pipeline (wholly unintentional on my part, but certainly
>> noticed) in its tracks.  (Yes, some data belong in OSM, some don't).
>
>
> I'm in strong agreement here. OSM provides a unique platform to synthesize
> multiple data sources in combination with field observation to produce
> something potentially better than any of these single sources are on their
> own. Trying to produce an accurate and detailed map of the entire US
> strictly off of field observation and satellite imagery is simply
> infesible, especially in remote, unpopulated areas. Many government and
> agency data sources are in conflict with each other over the same
> information; OSM can serve to provide "resolved" versions that are
> confirmed with ground observation where required.
>
> I agree that we shouldn't be importing parcel data wholesale, as-is. But,
> if real-life accuracy is important, the fact that much of the information
> we are trying to add in OSM (protected areas, land use, access
> restrictions) is differentiated along parcel boundaries is simply
> unavoidable to me. If this information is in the public domain and
> generally corroborates what is on the ground, so long as the data is worked
> through manually to confirm accuracy, I don't see the problem with using
> parcel information as a piece of the "puzzle" in producing an accurate and
> informative map.
> ___
> 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] Cooper Country State Forest in Keweenaw County, MI

[Joseph Eisenberg]

My goodness, look at that monstrosity:

https://www.openstreetmap.org/relation/1976405#map=8/46.459/-87.627

How can we claim that all of these patches of state-owned land constitute a
single OpenStreetMap feature?

-- Joseph Eisenberg

On Wed, Sep 2, 2020 at 10:27 AM Frederik Ramm  wrote:

> Hi,
>
> the DWG has been asked to remove this bit of land
>
> https://www.openstreetmap.org/way/146418027#map=13/47.3306/-88.4441
>
> from the "Cooper Country State Forest" protected area since it has been
> purchased from the state by private individuals in 2006 and "the recent
> plat books show this".
>
> I have been unable to find an online resource to corroborate this claim.
> Googling for "plat books" turned up some very pretty scans of 1800's
> surveyor records ;) Perhaps someone more knowledgeable in the US public
> records landscape can help?
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> 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] Opinions on Devil's Slide Bunker (San Mateo, CA)

[Joseph Eisenberg]

The tag military=bunker is used not only for true bunkers, but for "any
kind of military installation built to withstand an attack." - quote from
https://wiki.openstreetmap.org/wiki/Tag:military%3Dbunker

- Joseph Eisenberg

On Tue, Sep 1, 2020 at 12:10 PM Bill Ricker  wrote:

>
>
> On Sun, Aug 30, 2020, 19:55 stevea  wrote:
>
>> .  And if it was historically a bunker, OSM should strive to tag this,
>> I'm not exactly sure of the right mix of military=bunker and historic=yes
>> flavors that might be absolutely correct, but something like those if not
>> exactly those.  Though historic=ruins seems correct, too, so perhaps better
>> than "yes."
>>
>
> Technically this and most of what the public refers to as military bunkers
> aren't bunkers.
>
>  Many of the larger ones are casemated Coast Artillery gun positions and
> their magazines. These are protected to a degree better than a "bunker"
> from above, but had openings to seaward to fire which had only
> splinter-proof shielding, and these were not refuges for personel, so not
> true 'bunkers', they were fighting positions.
>
> Devil's Slide was a protected Fire Control post for Coast Artillery, and
> included a radar. (One could almost classify the radar control point as a
> bunker, as it had no windows nor fire ports, but again it's not a refuge.)
>
> http://www.fortwiki.com/Devil%27s_Slide_Military_Reservation
>
> I am a member of the Coast Defense Study Group (cdsg.org) as well as OSM.
> We study and seek to preserve these structures and the memories of those
> who built and served in them. One of our members was recently authorized to
> inspect Devil's Slide Reservation and reported on its current condition
> (and history) in an illustrated article in our Coast Defense Studies
> Journal. In addition to no-access signage it is gated and fenced. Tourist
> Safety is dubiously best as most of the handrails and safety lines are gone
> or deficient.
>
> (The nice thing about touring these sites with CDSG conferences - aside
> from knowledgeable companions - is that we negotiate "Authorized Persons
> Only" access, for which we sign copious liability waivers, and we equip and
> conduct ourselves appropriately for the expected hazards: hard hats or
> better, construction boots (or sometimes wellies/waders!), gloves,
> torches/flashlights, etc.)
>
> // Bill
>
>
> ___
> 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] Trouble with getting Superior National Forest

[Joseph Eisenberg]

The OpenStreetMap community has long agreed that mapping cadastral parcels
(land ownership) is not in scope. Protect area and National Park boundaries
were supposed to be less difficult to confirm and more valid.

But if what we are going to start mapping in the USA is simply the federal
ownership of land, that's just pure cadastre data. We might as well try to
map all the private land parcels and keep that information accurate - but
both tasks are too difficult, and the data is better provided by local
governments directly.

- Joseph Eisenberg

On Mon, Aug 31, 2020 at 9:50 PM Bradley White 
wrote:

>  If you drive into a checkerboard
>> area of private/public land, there are no Forest Service signs at the
>> limits of private land.
>>
>
> In my neck of the woods, USFS owned land is signed fairly frequently with
> small yellow property markers at the boundaries.
>
> Privately owned land within a NF declared boundary is not under any
> protection by the USFS, therefore tagging the administrative boundary as
> 'protected_area' will lead to inaccuracies. The land areas that are
> actually protected from development/have active resource management are
> only the lands which the federal government owns within these
> administrative boundaries.
>
> I think using the administrative boundaries is a good & practical first
> approximation, but the goal should eventually to be to change over to the
> actual land owned by the Fed and operated for conservation by the USFS.
>
>>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trouble with getting Superior National Forest boundary to render on standard map

[Joseph Eisenberg]

But the Forest Service itself is showing the outer boundary on it's
websites, as I've mentioned above. On the higher resolution web map, there
is only a faint difference in lighter green / darker green color to show
which land within the official boundary is privately or federally owned,
and this distinction is not even mentioned in the map legend:

https://www.fs.usda.gov/detailfull/klamath/maps-pubs/?cid=fseprd533703=full


And my experience is that only the outermost boundary has official signs
saying "entering Klamath National Forest". If you drive into a checkerboard
area of private/public land, there are no Forest Service signs at the
limits of private land.

- Joseph Eisenberg

On Mon, Aug 31, 2020 at 4:36 PM Kevin Kenny  wrote:

> On Mon, Aug 31, 2020 at 7:11 PM Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
>
>> I believe there might be an issue with these complex multipolygons which
>> is preventing osm2pgsql from handling them. Perhaps it is because nodes are
>> shared between two outer rings?
>>
>> However, I also want to note that it is not clear to me that the new
>> mapping is correct.
>>
>> The new outer boundaries for the Superior National Forest are very
>> complex and only cover a small portion of the land within the National
>> Forest outer boundary:
>>
>> https://www.openstreetmap.org/relation/11558095
>>
>> Compare the official National Forest web map:
>> https://usfs.maps.arcgis.com/apps/webappviewer/index.html?id=03a17ac9df1a4cd0bcc872ac996e7231
>> - this matches the older, simpler boundary that was in OpenStreetMap
>> previously. Also see this map on the Forest website:
>> https://www.fs.usda.gov/Internet/FSE_MEDIA/stelprdb5130373.pdf
>>
>> It appears that the new, complex relation is attempting to map what land
>> is owned by the Federal government, rather than mapping the legal boundary
>> of the National Forest. Is that correct?
>>
>> I believe this is a misinterpretation of the meaning of
>> boundary=protected_area.
>>
>
> They're both 'legal' boundaries.
>
> The simple outer boundary of a National Forest is 'the area in which the
> Forest Service is authorized to purchase land without a new Act of Congress
> expanding the forest.'  It's not signed in the field and has very little
> effect upon the actual land management. It's generally all that the
> enabling act of Congress specifies; the rest is done by having the law
> authorize the Executive Branch to determine the status of parcels within
> the legislated boundary.
>
> The outer boundary also generally excludes all 'inholdings' - private
> holdings that are enclosed by the national forest.
>
> It gives a more pleasant rendering at low zoom levels while still giving a
> sense of where the National Forest is, but does not reflect the situation
> in the field.
>
> The 'patchwork quilt' area is the area actually owned by the Federal
> Government and administered by the Forest Service. It's normally what will
> be posted in the field, and it's the area that actually enjoys the
> protection.
>
> For many Federally-administered land areas, there's also a third category:
> land on which the Federal government owns a conservation easement
> (essentially, the right to develop the land) but the land ownership (the
> right to exclude others) is private. There are huge pieces of wildlife
> refuges where Uncle Sam owns the hunting and development rights, but some
> farmer or forester owns and works the land.
>
> Most people in the general public would recognize only the most
> restrictive definition in the field, since that is what's signed. A duck
> hunter would look at an official map to see which of the private parcels
> comprising a wildlife refuge are open to the public for hunting in season.
> Very few people except the real estate lawyers care about the outermost
> boundary, except to give something that can yield a readable rendering on
> small-scale maps.
>
> I'm all for making the boundary follow the legal designation that has the
> greatest effect and is visibly signed.
> --
> 73 de ke9tv/2, Kevin
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trouble with getting Superior National Forest boundary to render on standard map

[Joseph Eisenberg]

I believe there might be an issue with these complex multipolygons which is
preventing osm2pgsql from handling them. Perhaps it is because nodes are
shared between two outer rings?

However, I also want to note that it is not clear to me that the new
mapping is correct.

The new outer boundaries for the Superior National Forest are very complex
and only cover a small portion of the land within the National Forest outer
boundary:

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

Compare the official National Forest web map:
https://usfs.maps.arcgis.com/apps/webappviewer/index.html?id=03a17ac9df1a4cd0bcc872ac996e7231
- this matches the older, simpler boundary that was in OpenStreetMap
previously. Also see this map on the Forest website:
https://www.fs.usda.gov/Internet/FSE_MEDIA/stelprdb5130373.pdf

It appears that the new, complex relation is attempting to map what land is
owned by the Federal government, rather than mapping the legal boundary of
the National Forest. Is that correct?

I believe this is a misinterpretation of the meaning of
boundary=protected_area.

See images at
https://github.com/gravitystorm/openstreetmap-carto/issues/4198#issuecomment-684084296
for another example with the Manistee National Forest, which used to be
mapped in a much simpler fashion and now has been re-made as many smaller
parcels.

- Joseph Eisenberg

On Sun, Aug 30, 2020 at 4:22 PM Clifford Snow 
wrote:

> Paul,
> I don't have a definitive answer for you, but rendering usually takes a
> while for large areas. I would expect it to render when zoomed in but
> wasn't able to see any rendering on a couple of spot checks. I did notice
> that around islands either the forest or the island, are shifted. I would
> recommend cleaning those up.
>
> Clifford
>
> On Sun, Aug 30, 2020 at 1:19 PM Paul White  wrote:
>
>> Hello,
>>
>> I recently added the (super complicated) Superior National Forest
>> boundary to OSM, because I noticed it was missing. However, it refuses to
>> render on the standard map, even though I ran it through JOSM's validator
>> with no problems. (link to relation)
>> <https://www.openstreetmap.org/relation/11558095#map=6/48.422/-92.439> I
>> don't think it's due to the amount of members, because the Tongass National
>> Forest I added recently, with over 10,000 members, renders fine. And I know
>> it's not due to the tags on the relation; they are standard to other
>> national forests.
>>
>> If someone could look into it and see what's causing it to break, that
>> would be great.
>>
>> pj
>>
>>
>> ___
>> 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
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Opinions on Devil's Slide Bunker (San Mateo, CA)

[Joseph Eisenberg]

Is the track closed to everyone, or is it perhaps access=private, if the
landowner has access?

There is also a more specific tag for military bunkers: military=bunker

https://wiki.openstreetmap.org/wiki/Tag%3Amilitary%3Dbunker

- Joseph Eisenberg

On Sun, Aug 30, 2020 at 12:16 PM brad  wrote:

> Agree, it seems pretty clear.   Even if the signs are universally
> ignored,  OSM shouldn't mislead everyone about the legality.
>
> On 8/30/20 12:01 PM, Frederik Ramm wrote:
> > Hi,
> >
> > "Devil's Slide Bunker" is a WW2 observation point near Pacifica in San
> > Mateo County in California.
> >
> > OSM has the bunker listed as a "tourism=viewpoint", along with access
> > tracks from the nearby CA-1 highway:
> >
> > https://www.openstreetmap.org/#map=19/37.56868/-122.51506
> >
> > The area is technically on private ground, and a sign at the location
> says:
> >
> > "Warning. Hiking or climbing prohibited in this area. This property is
> > designated as a dangerous area. It shall be unlawful to trespass
> > thereon. San Mateo County Ordinance No. 1462"
> > (http://www.remote.org/frederik/tmp/dssign.jpg)
> >
> > At the same time, searching the web shows tons of tourist guides that
> > recommend a visit to this prohibited place, replete with photos showing
> > lots of people around, and "Devil’s Slide Bunker sits on private
> > property and is technically not open to the public, but a nearby parking
> > area for the Devil’s Slide Trail, easy access along a short dirt trail,
> > and no fencing mean that people stop to check it out and walk around
> > every day."
> >
> > The DWG has received a complaint from a concerned citizen (via
> > AllTrails) complaining about this illegal tourist attraction on OSM.
> >
> > While it is undeniably a de-facto tourist attraction, and undeniably
> > offers great views, I think it should probably be changed to
> > historic=ruins, access=no, and the tracks leading up to it should also
> > be changed to access=no.
> >
> > Opinions?
> >
> > Best
> > Frederik
> >
>
>
> ___
> 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: [OSM-talk] Many processes not defined | Re: Proposal for Software Dispute Resolution Panel

[Joseph Eisenberg]

Re: "Rory, I don't know about you, but I'm certainly hoping for a bunch of
corporate sell outs rubber stamping iD decisions and squashing the common
mapper into conformity. Why else would we be doing this?"

This sarcastic comment is not a fair response to Christoph's concerns.

While we hope that no one involved currently in OpenStreetMap would
purposefully turn the community over to corporations, it is certainly
possible to imagine this to happen little by little, if the community is
eroded slowly, lacking safeguards and clear goals.

If the people who become leaders of the OpenStreetMap community have all of
their experience and ideals based in the corporate tech sector, it will be
unsurprising if they are naturally inclined to make decisions which are
favorable to the interests of Facebook, Apple or Amazon, whether or not
they benefit the OpenStreetMap community.

As a famous American reformer (Upton Sinclair) often said: "It is difficult
to get a man to understand something, when his salary depends upon his not
understanding it."

– Joseph Eisenberg

On Tue, Aug 4, 2020 at 2:08 PM Mikel Maron  wrote:

> Rory, I don't know about you, but I'm certainly hoping for a bunch of
> corporate sell outs rubber stamping iD decisions and squashing the common
> mapper into conformity. Why else would we be doing this?
>
> On Tuesday, August 4, 2020, 04:37:00 PM EDT, Rory McCann <
> r...@technomancy.org> wrote:
>
>
>
>
>
> The Board hasn't decided on how the panel will be
> formed/elected/appointed/choosen. Just because the document doesn't
> address one issue, doesn't mean the opposite, horrible option will
> happen. Do you think I'm going to support some Old Boy's Network of
> corporate employees?
>
> What would you suggest for appointing & transparency?
>
> On 04.08.20 21:30, Christoph Hormann wrote:
> > On Tuesday 04 August 2020, Dorothea Kazazi wrote:
> >>
> >> The OSMF board just published a proposal for a software
> >> dispute resolution panel:
> >> https://blog.openstreetmap.org/2020/08/04/proposal-for-software-dispu
> >> te-resolution-panel/
> >
> > I guess i am asking too much if i envision the board creating a panel it
> > does not control itself...
> >
> > For context - the DWG, which is the traditional and broadly respected
> > entity to resolve conflicts in mapping, is not controlled in
> > composition by the board, it decides on accepting new members
> > themselves.  See also:
> >
> >
> https://wiki.osmfoundation.org/wiki/Data_Working_Group/DWG_Membership_Policy
> >
> https://wiki.osmfoundation.org/wiki/Data_Working_Group/DWG_Conflict_of_Interest_Policy
> >
> > Significant parts of the authority the DWG has among mappers derive from
> > the fact that it is not composed of political appointees.
> >
> > Interesting also that the composition of the panel is supposed to
> > reflect "all interests of the OSM community" but competence of the
> > panel members on the subject, experience with and knowledge of mapping
> > and tagging in OSM or in other words:  The competence to assess
> > evidence on the cases they deal with and to deliberate on the matters
> > in a qualified and knowledgable way, is not a criterion.  Neither is
> > impartiality on prominent special interests like those of corporate
> > data users.
> >
> > Transparency is limited to the ultimate decisions being made public
> > (indeed important, would be interesting how this would function
> > otherwise).  I guess that means both the nominations and selection of
> > panel members as well as the deliberation and consulting of the panel
> > on cases is going to happen behind closed doors.
> >
>
> ___
> 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 mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[Joseph Eisenberg]

We should not ask anyone to do 2 months development work for 2500 euros.

I believe this size grant is only enough for 1 to 2 weeks, based on
international prices (though
I do not have any paid experience in this field)

- Joseph Eisenberg

On Tue, Aug 4, 2020 at 4:08 AM pangoSE  wrote:

> I disagree. For that sum of money I would be willing to start writing a
> new editor in Rust compiled to WebAssembly and desktop and reach a state of
> basic editing useability in 2 months.
> See also https://www.youtube.com/watch?v=ohuTy8MmbLc
> Cheers
>
> Joseph Eisenberg  skrev: (3 augusti 2020
> 01:00:49 CEST)
>
>> While the benefit of making Potlatch 2 on AIR is small, the cost is tiny.
>>
>> 2500 Euros is an insignificant price to pay for supporting an editor
>> which is still used by a couple of thousand long-term users.
>>
>> I support this expenditure.
>>
>> – Joseph Eisenberg
>>
>> On Sun, Aug 2, 2020 at 10:05 AM Alexandre Oliveira 
>> wrote:
>>
>>> I'd like to share my two cents on the matter of supporting Potlatch 2,
>>> an editor built with (now) dead technology.
>>>
>>> I don't think it's worth spending money to update P2 to Air. As others
>>> have stated, Air has been discontinued as well, and it was developed
>>> by Adobe, probably with the same amount of security flaws as Flash
>>> had, which contributed to its demise. I don't see Air as different
>>> even though it's being maintained now by Samsung.
>>>
>>> Just take a look. The web is different than when P2 released; flash is
>>> deprecated and a synonym for vulnerable systems, Air tried to take off
>>> but now it's just another dead technology. What are the benefits of
>>> porting P2 to Air? It may be easier because Air may share some code
>>> with Flash, which in turn makes it easier to port to.
>>>
>>> However, I think that the OSMF should find someone familiar with Flash
>>> and look forward to porting P2 to modern web technologies (please not
>>> Electron!), like WebAssembly or Web 2.0. Be it JavaScript,
>>> CoffeeScript or TypeScript, React, Angular, Vue.js or any other modern
>>> web tech, it doesn't matter. I think it's going to be money well spent
>>> if P2 was ported to a supported web technology and not something that
>>> died a few years ago and is on life support, and barely anyone uses it
>>> nowadays.
>>>
>>> IMO porting P2 to Air is just a waste of money and time from the
>>> developer, and we will reach the same point in the future, be it
>>> either for deprecating P2 or looking to port it to newer web
>>> technologies. OSMF should prepare for the future and not continue
>>> using deprecated technology.
>>>
>>> ___
>>> 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 mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[Joseph Eisenberg]

While the benefit of making Potlatch 2 on AIR is small, the cost is tiny.

2500 Euros is an insignificant price to pay for supporting an editor which
is still used by a couple of thousand long-term users.

I support this expenditure.

– Joseph Eisenberg

On Sun, Aug 2, 2020 at 10:05 AM Alexandre Oliveira 
wrote:

> I'd like to share my two cents on the matter of supporting Potlatch 2,
> an editor built with (now) dead technology.
>
> I don't think it's worth spending money to update P2 to Air. As others
> have stated, Air has been discontinued as well, and it was developed
> by Adobe, probably with the same amount of security flaws as Flash
> had, which contributed to its demise. I don't see Air as different
> even though it's being maintained now by Samsung.
>
> Just take a look. The web is different than when P2 released; flash is
> deprecated and a synonym for vulnerable systems, Air tried to take off
> but now it's just another dead technology. What are the benefits of
> porting P2 to Air? It may be easier because Air may share some code
> with Flash, which in turn makes it easier to port to.
>
> However, I think that the OSMF should find someone familiar with Flash
> and look forward to porting P2 to modern web technologies (please not
> Electron!), like WebAssembly or Web 2.0. Be it JavaScript,
> CoffeeScript or TypeScript, React, Angular, Vue.js or any other modern
> web tech, it doesn't matter. I think it's going to be money well spent
> if P2 was ported to a supported web technology and not something that
> died a few years ago and is on life support, and barely anyone uses it
> nowadays.
>
> IMO porting P2 to Air is just a waste of money and time from the
> developer, and we will reach the same point in the future, be it
> either for deprecating P2 or looking to port it to newer web
> technologies. OSMF should prepare for the future and not continue
> using deprecated technology.
>
> ___
> 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] Proper use of route relations?

[Joseph Eisenberg]

No

Relations are not collections

- Joseph Eisenberg

On Sat, Aug 1, 2020 at 9:23 AM Mike Thompson  wrote:

> I have come across a number of examples[0] of route relations where all
> the trails in a given park have been put into a single relation.  Is this a
> recommended use for route relations?
>
> Mike
>
> [0]
> https://www.openstreetmap.org/relation/10962561
> https://www.openstreetmap.org/relation/8409089
>
> ___
> 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

[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: [Talk-us] Coconino National Forest boundary isn't rendering anymore?

[Joseph Eisenberg]

>  Coconino's boundary IS rendering, but with more accurate tags, and
differently than a national_park

That's incorrect. It's not rendering at all on the highest zoom levels,
which have been refreshed most recently.

boundary=national_park and boundary=protected_area are rendered identically
in the relevant map style:
https://github.com/gravitystorm/openstreetmap-carto/blob/master/style/admin.mss#L496

- Joseph Eisenberg

On Thu, Jul 16, 2020 at 10:55 AM stevea  wrote:

> On Jul 16, 2020, at 10:13 AM, Joseph Eisenberg 
> wrote:
> > It's not the tagging. Other relations with boundary=protected_area +
> protect_class=6 are rendering fine in the OpenStreetMap Carto style. The
> code is here:
> https://github.com/gravitystorm/openstreetmap-carto/blob/5724017f5b549ba954d9d645c0b2383dd16237d1/project.mml#L1132-L1149
> - boundary=protected_area + protect_class=6 is enough.
>
> To repeat myself, I believe Joseph and I agree / are saying largely the
> same thing here:  there isn't anything to "fix," as boundary=protected_area
> + protect_class=6 renders fine in Carto, and that is how Coconino is now
> (more correctly) tagged.
>
> Given the recent history of this multipolygon's tags being changed from
> national_park to protected_area (both of which render, but slightly
> differently), if original poster Paul wants to add clarity to why he
> believes this "isn't rendering anymore" I welcome what he might add or
> additionally ask.  However, I believe the relevant issues to be addressed
> have been.  The answer is "Coconino's boundary IS rendering, but with more
> accurate tags, and differently than a national_park, which is how it was
> previously though incorrectly tagged."
>
> SteveA
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Coconino National Forest boundary isn't rendering anymore?

[Joseph Eisenberg]

It's not the tagging. Other relations with boundary=protected_area +
protect_class=6 are rendering fine in the OpenStreetMap Carto style. The
code is here:
https://github.com/gravitystorm/openstreetmap-carto/blob/5724017f5b549ba954d9d645c0b2383dd16237d1/project.mml#L1132-L1149
- boundary=protected_area + protect_class=6 is enough.

– Joseph


On Thu, Jul 16, 2020 at 6:24 AM stevea  wrote:

>  Paul White  wrote:
> > Does anybody know why the Coconino National Forest doesn't render on
> osm.org anymore? I don't see any recent changes that would've messed
> anything up but it's gone. I also noticed that the Klamath National Forest
> is gone, as well.
>
> I'm glad to see august and more-technical members of OSM (Paul Norman,
> Joseph Eisenberg...) chiming into this thread.
>
> I am the most recent author of this relation.  I made minor changes to the
> tags on the relations, not the members or their roles.  Specifically, the
> edit History (click View History link at bottom of object "pane") displays
> the previous set of tags (and seems to have rendered to the o.p.'s liking),
> which included:
>
> boundary=national_park + boundary:type=protected_area
>
> while the present tags exclude those, but include:
>
> boundary=protected_area + protect_class=6
>
> I did this because boundary=national_park is not a valid tag on a USFS
> National Forest per our evolving wiki
> https://wiki.osm.org/wiki/United_States/Public_lands , which
> prescriptively suggests this tagging.
>
> I believe it is safe to assume that the previous tagging of
> boundary=national_park was incorrectly applied because it rendered, and
> that the somewhat clumsy and collides-with tag boundary:type=protected_area
> was added to be more consistent with the newer tagging scheme of
> protected_area, though it excluded the associates-with tag of
> protect_class=6 which my newer tagging added, along with the "proper" key
> of boundary, not boundary:type.  If you followed all that, thank you.
>
> The particular combination of boundary=protected_area + protect_class=6
> does render (as a thin green line and an occasional name=* value along
> edges).  And again, boundary=national_park renders, though differently than
> boundary=protected_area + protect_class=6 — and rightly so, as these ARE
> different entries:  a national park is not a national forest and vice versa.
>
> > If anyone knows how to fix this, let me know.
>
> I believe there isn't anything to "fix" here:  what appears to have
> happened is that a wrong-tagging which rendered with a certain appearance
> was corrected to be "more properly" tagged, and this renders, but
> differently.  As these are issues which may continue to be evolving
> (relatively newer tagging schemes like protected_area compared to
> national_park, as well as rendering support, or lack thereof, for various
> values of protect_class), it is possible I lack full clarity into either
> the present exception of or intended effects of these tags and the Carto
> renderer.  Here, I only offer my best explanation of present tagging and
> rendering effects, not future ones.
>
> SteveA
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Coconino National Forest boundary isn't rendering anymore?

[Joseph Eisenberg]

Re: "recursion limits of the geometry assembler." - is this merely due to
the large number of inner and outer ways?

Is it related to the nodes that are shared by 2 outer ways?

– Joseph E.

On Wed, Jul 15, 2020 at 3:24 PM Paul Norman via Talk-us <
talk-us@openstreetmap.org> wrote:

> On 2020-07-15 3:00 p.m., Paul White wrote:
>
> Does anybody know why the Coconino National Forest doesn't render on
> osm.org anymore? I don't see any recent changes that would've messed
> anything up but it's gone. I also noticed that the Klamath National Forest
> is gone, as well.
>
> I assume you're talking about
> https://www.openstreetmap.org/relation/10956348#map=15/35.1483/-111.6705?
> It is rendered - you can see the green outline and text.
>
> https://www.openstreetmap.org/relation/11239975 is a different issue. It
> looks like it might be complex enough that it hits the recursion limits of
> the geometry assembler.
> ___
> 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: [OSM-talk] Paid mapping

[Joseph Eisenberg]

Please clarify: are the Apple mappers 1) changing the ways to
highway=track, or 2) changing ways that are currently highway=track to
something else?

I would support #2 in any case where the way connects settlements, since we
have always defined highway=track as a way that is used for agriculture,
forestry etc., not for travel between settlements.

– Joseph Eisenberg

On Mon, Jun 22, 2020 at 11:17 AM John Whelan  wrote:

> I've noticed a number of highways being changed in Africa from
> unclassified to track and from unclassified to tertiary.The ones I've
> noticed are Apple mappers usually with the comment of from Bing and often
> the highways connect settlements so should be a minimum of unclassified or
> path but not track.
>
> African highway wiki  says it is difficult to classify highways without
> local knowledge above unclassified.  Track is fairly easy it doesn't
> connect settlements according to the wiki.
>
> Do I get the impression we are talking targets here?  The paid mappers
> have to do so many edits to meet their targets and changing the
> classification using Bing is easier than adding to the map?
>
> Do we care?  Is it is just something to be aware of.
>
> Thoughts?
>
> Thanks
>
> Cheerio John
> --
> Sent from Postbox <https://www.postbox-inc.com>
> ___
> 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] National Forest boundaries

[Joseph Eisenberg]

> I was thinking just create separate polygons for inholdings, tagged with
access=private and possibly ownership=private

While many Americans like to put "no trespassing" signs on their private
property, a privately owned parcel is not access=private unless there are
signs on the roads and paths leading into it which say so.

Many privately-owned parcels in the national forests are used for forestry
only, and there is no issue with crossing through on a road or trail in
many cases.

Generally it is difficult to maintain land ownership data in OpenStreetMap.
Fortunately, in the USA there are publicly-available databases which
contain this cadastral information, so it is not necessary for us to
duplicate it in OpenStreetMap. Database users should expect to get land
ownership information directly from official sources, if they want accurate
and up-to-data land ownership info by parcel.

For example in Oregon you can get data at
https://www.oregon.gov/geo/Pages/sdlibrary.aspx

We should not try to map all land ownership data by parcel in OpenStreetMap.

– Joseph Eisenberg

On Sat, Jun 20, 2020 at 5:23 PM stevea  wrote:

> Mike, I hadn't considered that, it distinctly deepens the discussion.
> Stroking my chin and saying "hm" now.
> 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-us] Import of addresses for San Francisco, CA

[Joseph Eisenberg]

Legally in San Francisco does the address refer to the property, the
building, or the entrance?

While I'm from California originally, I admit that I don't know the
definition of an address there.

If one building can have more than one address (based on separate
entrances), then it would be best to use nodes.

- Joseph Eisenberg

On Thu, Jun 18, 2020 at 9:36 AM Yury Yatsynovich 
wrote:

> I saw addresses in SF mapped both ways -- some are mapped as nodes inside
> the buildings or on contours of buildings (as entrances); others are added
> directly on the ways/relations of buildings.
>
> On Thu, Jun 18, 2020 at 12:20 PM Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
>
>> >  matching buildings to address points
>>
>> I support the idea of adding missing addresses. However, is it best
>> practice to match the address with the building area?
>>
>> Currently in SF are almost all addresses matched with buildings, or are
>> some mapped as nodes or separate area features?
>>
>> -- Joseph Eisenberg
>>
>> On Thu, Jun 18, 2020 at 8:30 AM Yury Yatsynovich <
>> yury.yatsynov...@gmail.com> wrote:
>>
>>> Greetings!
>>>
>>> I've been recently thinking about importing addresses for San Francisco,
>>> CA.
>>> It looks like there has been interest in this kind of import (the page
>>> devoted to it was created in 2010,
>>> https://wiki.openstreetmap.org/wiki/San_Francisco_Address_Import).
>>>
>>> So, please, consider this message as my "community buy-in": does anyone
>>> have any objections related to this possible import?
>>> By now I've obtained a permit from the data owner (
>>> https://data.sfgov.org/Geographic-Locations-and-Boundaries/Addresses-Enterprise-Addressing-System/3mea-di5p)
>>> and almost finished writing my code for matching buildings to address
>>> points.
>>>
>>> If there are no objections, I'll go on with organising all documentation
>>> and sharing the code/resulting .osm-files for review by OSM community.
>>>
>>> Looking forward to receiving your feedback!
>>>
>>> p.s. I have some experience in importing addresses (e.g., see
>>> https://wiki.openstreetmap.org/wiki/Import/Catalogue/MassGIS_Addresses)
>>>
>>>
>>>
>>>
>>> --
>>> Yury Yatsynovich
>>> ___
>>> Talk-us mailing list
>>> Talk-us@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-us
>>>
>>
>
> --
> Yury Yatsynovich
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?

[Joseph Eisenberg]

I mostly have mapped in parts of Indonesia where there was no data, and the
new road or river was mapped for the first time.

Usually I try to split roads and rivers every ~10 kilometers.

- Joseph Eisenberg

On Sat, Jun 13, 2020 at 8:46 AM Mateusz Konieczny via talk <
talk@openstreetmap.org> wrote:

>
>
>
> Jun 13, 2020, 08:03 by f...@zz.de:
>
> On Fri, Jun 12, 2020 at 11:19:46AM -0400, James wrote:
>
> No they shouldn't, mapping roads in northern Canada, your bbox can become
> quite large quickly as mapping logging roads/dirt roads is quick and easy,
> but span over multiple kms
>
>
> The point is that the line/way of that road should also not span tens of
> kms. You should break that up every couple of kilometers.
>
> Not alway, there are reasonable cases for mapping long roads without such
> splits.
>
> In many poorly mapped places you can still map 100km of road/river
> in one go, without need for splitting it.
>
> ___
> 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] [OSM-talk] Google earth, Google maps

[Joseph Eisenberg]

You should check the measurement directly from aerial imagery in iD or
JOSM, or by visiting the location in person and measuring or estimating.

On Sat, Jun 13, 2020 at 9:24 AM 80hnhtv4agou--- via Talk-us <
talk-us@openstreetmap.org> wrote:

> since the complainer removed the source (google map) do i remove the # as
> well ?
>
>
>
> Saturday, June 13, 2020 11:09 AM -05:00 from Mike Thompson <
> miketh...@gmail.com>:
>
>
>
> According to the Google Maps Terms of service, you cannot use it in any
> way to make another map. [0]  I would think that would include using its
> ruler if the purpose of using the ruler is to edit OSM.
>
> [0] 2.d of https://www.google.com/help/terms_maps/
>
> On Sat, Jun 13, 2020 at 9:47 AM 80hnhtv4agou--- via Talk-us <
> talk-us@openstreetmap.org
> > wrote:
>
> because i was asked to change my edit based on my own ruler measurement,
>
> but it was just a ruler on google maps.
>
>
> Saturday, June 13, 2020 10:42 AM -05:00 from Mateusz Konieczny via Talk-us
>  >:
>
> If you were not copying Google Maps then why you were using the ruler?
>
> Why using ruler on Google Maps would be even necessary?
>
> Jun 13, 2020, 17:31 by t...@openstreetmap.org
> :
>
> i put them as a source i used a ruler on there map.
>
>
>
> Saturday, June 13, 2020 10:20 AM -05:00 from Mateusz Konieczny via talk <
> t...@openstreetmap.org >:
>
>
>
>
> Jun 13, 2020, 16:59 by eric.lad...@gmail.com
> :
>
> Yeah, be careful with Google Maps.  It's owned and created by a company
> and if you copy from it and they can prove it, they could sue the OSM
> Foundation into oblivion.  They used to even have their OWN satellites to
> obtain imagery.  That's serious money.
>
> That is not the main problem. Main problem is that it goes our own
> fundamental rules.
> Mappers must not use other maps* even if whoever hold copyright is unable
> to sue for some reason.
>
> And "they can prove it" part may be misleading - you are not allowed to
> copy even if you think that
> you can hide the copying so that noone will notice it.
>
> *that is more complicated, we are must not copyrighted data on
> incompatible licenes -
> but if you are unsure what it means do not use other maps and ask for help
> before doing this
>
>
> Typically, with local edits, I put "Local knowledge" as the source.
> Sounds more highbrow than "my eyeballs".
>
> I usually put survey/memory depending on how recent my data is.
>
> IMO, if somebody is challenging one of your local edits, if they are not
> local also, they should be told as much and sent on their way - UNLESS it's
> something that relates to a mapping standard or best practice.  Then, learn
> from your mistakes and move on.
>
> +1
>
> On Sat, Jun 13, 2020 at 9:32 AM 80hnhtv4agou--- via Talk-us <
> talk-us@openstreetmap.org> wrote:
>
> this was a tool on the map that measured distance.
>
> Have you copied that map? I am unsure how the distance measuring tool
> relates to "why are you telling me I can not use google as a map source"?
>
>
>
> Saturday, June 13, 2020 9:29 AM -05:00 from Mateusz Konieczny via Talk-us <
> talk-us@openstreetmap.org>:
>
> You are not allowed to use Google Maps as source.
>
> Have you used Google Maps to edit OSM?
>
> "since all the maps on OSM are old news like in my local area 7 months
> old."
>
> FYI, world is larger than your local area.
>
>
> Jun 13, 2020, 16:08 by talk-us@openstreetmap.org:
>
> If you people want me to prove my edit by adding a source, and a person
> from the data group as an editor,
>
> asks me to prove it, and i redo my edit and he does not get back to me,
> why are you telling me I can not use
>
> google as a map source, since all the maps on OSM are old news. like in my
> local area 7 months old.
>
>
>
>
> ___
> 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
>
>
>
> --
> Eric Ladner
>
>
> ___
> talk mailing list
> t...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
>
>
>
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
>
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> 
> https://lists.openstreetmap.org/listinfo/talk-us
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
>
>
>
> ___
> Talk-us mailing list
> 

Re: [OSM-talk] [Talk-us] Google earth, Google maps

[Joseph Eisenberg]

You should check the measurement directly from aerial imagery in iD or
JOSM, or by visiting the location in person and measuring or estimating.

On Sat, Jun 13, 2020 at 9:24 AM 80hnhtv4agou--- via Talk-us <
talk...@openstreetmap.org> wrote:

> since the complainer removed the source (google map) do i remove the # as
> well ?
>
>
>
> Saturday, June 13, 2020 11:09 AM -05:00 from Mike Thompson <
> miketh...@gmail.com>:
>
>
>
> According to the Google Maps Terms of service, you cannot use it in any
> way to make another map. [0]  I would think that would include using its
> ruler if the purpose of using the ruler is to edit OSM.
>
> [0] 2.d of https://www.google.com/help/terms_maps/
>
> On Sat, Jun 13, 2020 at 9:47 AM 80hnhtv4agou--- via Talk-us <
> talk...@openstreetmap.org
> > wrote:
>
> because i was asked to change my edit based on my own ruler measurement,
>
> but it was just a ruler on google maps.
>
>
> Saturday, June 13, 2020 10:42 AM -05:00 from Mateusz Konieczny via Talk-us
>  >:
>
> If you were not copying Google Maps then why you were using the ruler?
>
> Why using ruler on Google Maps would be even necessary?
>
> Jun 13, 2020, 17:31 by talk@openstreetmap.org
> :
>
> i put them as a source i used a ruler on there map.
>
>
>
> Saturday, June 13, 2020 10:20 AM -05:00 from Mateusz Konieczny via talk <
> talk@openstreetmap.org >:
>
>
>
>
> Jun 13, 2020, 16:59 by eric.lad...@gmail.com
> :
>
> Yeah, be careful with Google Maps.  It's owned and created by a company
> and if you copy from it and they can prove it, they could sue the OSM
> Foundation into oblivion.  They used to even have their OWN satellites to
> obtain imagery.  That's serious money.
>
> That is not the main problem. Main problem is that it goes our own
> fundamental rules.
> Mappers must not use other maps* even if whoever hold copyright is unable
> to sue for some reason.
>
> And "they can prove it" part may be misleading - you are not allowed to
> copy even if you think that
> you can hide the copying so that noone will notice it.
>
> *that is more complicated, we are must not copyrighted data on
> incompatible licenes -
> but if you are unsure what it means do not use other maps and ask for help
> before doing this
>
>
> Typically, with local edits, I put "Local knowledge" as the source.
> Sounds more highbrow than "my eyeballs".
>
> I usually put survey/memory depending on how recent my data is.
>
> IMO, if somebody is challenging one of your local edits, if they are not
> local also, they should be told as much and sent on their way - UNLESS it's
> something that relates to a mapping standard or best practice.  Then, learn
> from your mistakes and move on.
>
> +1
>
> On Sat, Jun 13, 2020 at 9:32 AM 80hnhtv4agou--- via Talk-us <
> talk...@openstreetmap.org> wrote:
>
> this was a tool on the map that measured distance.
>
> Have you copied that map? I am unsure how the distance measuring tool
> relates to "why are you telling me I can not use google as a map source"?
>
>
>
> Saturday, June 13, 2020 9:29 AM -05:00 from Mateusz Konieczny via Talk-us <
> talk...@openstreetmap.org>:
>
> You are not allowed to use Google Maps as source.
>
> Have you used Google Maps to edit OSM?
>
> "since all the maps on OSM are old news like in my local area 7 months
> old."
>
> FYI, world is larger than your local area.
>
>
> Jun 13, 2020, 16:08 by talk...@openstreetmap.org:
>
> If you people want me to prove my edit by adding a source, and a person
> from the data group as an editor,
>
> asks me to prove it, and i redo my edit and he does not get back to me,
> why are you telling me I can not use
>
> google as a map source, since all the maps on OSM are old news. like in my
> local area 7 months old.
>
>
>
>
> ___
> Talk-us mailing list
> talk...@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
>
>
>
> ___
> Talk-us mailing list
> talk...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
>
> --
> Eric Ladner
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
>
>
>
>
>
> ___
> Talk-us mailing list
> talk...@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
>
>
>
> ___
> Talk-us mailing list
> talk...@openstreetmap.org
> 
> https://lists.openstreetmap.org/listinfo/talk-us
>
> ___
> Talk-us mailing list
> talk...@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
>
>
>
> ___
> Talk-us mailing list
> 

Re: [Talk-us] Off-highway vehicle recreation areas

[Joseph Eisenberg]

A leisure=park is supposed to be similar to a town park; an area with
managed vegetation where you might walk around or recreate. An OHV area is
not like this: "A park is an area of open space for recreational use,
usually designed and in semi-natural state with grassy areas, trees and
bushes. ... This tag is intended for (usually urban) parks with managed
greenery, located within settlements and nearly always open to general
public."

The tag leisure=sports_centre might be appropriate for an area that is
specifically developed and designed for ATVs and motorcycles.

"A *sports centre* is a distinct facility where sports take place within an
enclosed area. It can be a building (indoor sports centre), just outside
(outdoor sports centre) or contain indoor and outdoor sports features mixed
together."

However, if this is a large semi-natural area that just happens to have a
number of track or trails, then it's similar to a forested area with hiking
trails or mountain bike paths. In this case it might or might not be part
of a boundary=protected_area

In the case of the Hungary Valley SVRA, it is managed by the California
State Parks system: https://www.parks.ca.gov/?page_id=405 - I believe this
is a boundary=protected_area

-- Joseph Eisenberg

On Sat, Jun 6, 2020 at 12:54 PM brad  wrote:

> Good question.   At first glance I don't think Leisure=park is wrong.  The
> wiki is characteristically narrow since it says that it is green.
> leisure=sports_center or landuse=recreation_ground would be better.
> leisure=pitch doesn't seem right even thought the sport=motocross wiki page
> references it.   These OHV areas are typically more than a simple motocross
> track.   leisure=nature_reserve sure doesn't seem right!
>
> On 6/5/20 4:55 PM, Tod Fitch wrote:
>
> I have noticed a couple of off-highway vehicle recreation areas that are 
> tagged with things that seem incorrect to me: As generic parks or as 
> protected areas.
>
> Consider the Hungry Valley State Vehicle Recreation Area [1][2][3][4] and the 
> Wildomar OHV Area [5][6].
>
> My problem is that I can’t tell from the wiki and taginfo what might more 
> appropriate or more accepted tagging. It seems there is tagging for tracks 
> used for motocross. And people have used access tags for ATVs. But I don't 
> see a documented tagging for an area that contains a trail system for use by 
> multiple types of off-highway vehicles. I have some thoughts on what might be 
> appropriate, but would rather hear from others.
>
> Thanks!
>
> --Tod
>
> [1] 
> https://www.riderplanet-usa.com/atv/trails/info/california_10003/ride_413b.htm
> [2] https://www.openstreetmap.org/relation/6179378
> [3] https://www.openstreetmap.org/way/367714413
> [4] https://www.openstreetmap.org/way/367714414
> [5] 
> https://www.riderplanet-usa.com/ATV/trails/info/california_03947/ride_7684.htm
> [6] https://www.openstreetmap.org/way/248540505
>
>
> ___
> 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
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Heavily-wooded residential polygons

[Joseph Eisenberg]

>  should the entirety of the underlying area be tagged landuse=farmland or
landuse=residential?

Neither: just tag the areas that are used for residences as
landuse=residential, and the area used for farming (mostly crops) as
landuse=farmland.

In OpenStreetMap we want to map what is actually there, not the zoning or
legal landuse or property boundaries.

This might change next year, just like an unmown meadow may change back
into scrubland, and then eventually into woodland, or how a river will
meander over time.

Map what is there in reality right now, to your best ability. If people
want to know the legal zoning or property boundaries there are plenty of
data sources for that information, but OpenStreetMap is valueable because
it provides local knowledge of what is really there.

–Joseph Eisenberg

On Tue, Jun 2, 2020 at 1:19 PM stevea  wrote:

> Mateusz Konieczny  wrote:
> > I think that it is not a good assumption. One may have a property
> boundary that is partially landuse=residential and partially
> landuse=industrial/farmland
>
> I have mentioned before that the values OSM documents for the landuse key,
> while good, are incomplete with the great richness by which the world
> recognizes and categorizes these.  Here, Mateusz mentions a "triple" where
> residential, industrial and farmland exist together (or perhaps "double"
> where the latter two are blended, a certain kind of "single" activity, so
> when the residence is added, this makes two distinct landuses in total).
>
> I myself have mentioned what are locally known as "residential /
> agricultural" areas, which I characterize as a "live on family farm."
> These consist of a residence (house) and small (one to ten hectares) or
> medium-to-large (ten hectares and larger) areas where a wide variety of
> agriculture either can or might take place.  Some areas are substantially
> tree-covered and give rise to wild mushroom gathering, what I am told is a
> "fruits of the forest" activity, not "farmland."  On these (especially in
> clearings, grassland/meadow areas), I often find
> landuse=greenhouse_horticulture, landuse=orchard and landuse=vineyard areas
> which "crop up" and appear in imagery.  Because OSM has specific tags for
> these, I tag them as I see them.  However, should the entirety of the
> underlying area be tagged landuse=farmland or landuse=residential?  The
> truth is, "they are both," but OSM hasn't a
> landuse=live_on_family_farm_that_gives_rise_to_tree-planting_viticulture_and_hothouses
> tag.
>
> Getting the entirety of the world to agree upon values which seem very
> highly locally-dependent and articulated seems difficult.  The alternative
> is to have our renderers only approximate the tagging mappers are
> encouraged to "shoehorn" into, given these many, often subtle, landuse
> distinctions.
>
> Another complicating factor is "actual landuse" vs. "potential landuse,"
> (does take place vs. can or might take place) where some say to "tag only
> what is actual."  Others see this approach as a removal of land rights,
> further muddying what OSM means by landuse.
>
> These issues truly are complicated, I believe it is easy to agree.
>
> 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

[Talk-us] Stay-Healthy Streets in Seattle do not appear to be Living Streets

[Joseph Eisenberg]

Some mappers have suggested using highway=living_street for streets in
Seattle (and perhaps elsewhere) which temporarily have through-traffic
restricted for motor vehicles. However, this appears to be incorrect usage
of the tag.

According to the announcement by SDOT, the streets in the Stay-Healthy
Streets program have a speed limit of 32 kph (20 mph), much higher than the
maximum for a Living Street (20 kmh to "walking speed"). It appears that
the legal change is that these streets are now motor_vehicle=destination,
with through-traffic prohibited, but they are not Living Streets according
to the description in this page or at Wikipedia:

"designed primarily with the interests of pedestrians and cyclists in mind
and as a social space where people can meet and where children may also be
able to play legally and safely... vehicle parking may be restricted".
"These streets are often built at the same grade as sidewalks, without
curbs. Cars are limited to a speed that does not disrupt other uses of the
streets (usually defined to be pedestrian speed), or through traffic is
eliminated using bollards or circuitous one-way operation. To make this
lower speed natural, the street is normally set up so that a car cannot
drive in a straight line for significant distances, for example by placing
planters at the edge of the street, alternating the side of the street the
parking is on, or curving the street itself. Other traffic calming measures
are also used."

The streets in Seattle have street parking along their whole lengths, and
there are no design changes compared to other highway=residential streets
in the city, except for signage / paint.

While I would personally love to see real Living Streets in the USA, it
doesn't appear that this tag should be used in Seattle (or Portland, where
we have implemented similar short-term policies on "Neighborhood
Greenways") at this time. If the city redesigns these streets and lowers
the speed limit to 5 or 10 mph and legally allows pedestrians to use the
whole street at any times, then we can reconsider.

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

Re: [Talk-us] Heavily-wooded residential polygons

[Joseph Eisenberg]

Could you provide a link to a particular location you are thinking of?

When I map farms in Papua, Indonesia, usually there is a central
residential compound with a few small houses and farm buildings, and
usually some shade and fruit trees right between the houses. I map that
residential area as landuse=residential. Sometimes there is a yard for
raising chickens and pigs or a large pig stye and dirt area nearby; that
can be mapped as landuse=farmyard. Then if there are vegetables gardens I
map those as landuse=farmland. Any fields planted with bananas or (fruit)
palms are landuse=orchard. Fallow fields are usually landuse=meadow if they
are covered in grass, though after a few years they turn back into
natural=scrub and eventually natural=wood - the locals use a very long
rotation period.

So, each area is mapped with what it is used for. This means that the
different landuse areas can be pretty small. E.g.:
https://www.openstreetmap.org/#map=17/-4.08508/138.73589

In the parts of Europe I've seen even smaller patches of different areas:
https://www.openstreetmap.org/#map=17/38.55129/-28.66001
That looks like a lot of work! It's totally okay to start by just mapping
large areas imprecisely, and then later we can get it down to very precise
mapping of thin strips of trees and scrub between fields:
https://www.openstreetmap.org/way/628402941 - if we want to

Joseph

On Thu, May 28, 2020 at 6:48 PM stevea  wrote:

> On May 28, 2020, at 5:12 PM, Joseph Eisenberg 
> wrote:
> > >  beekeeping, wild mushroom harvesting, herb-crafting for essential oils
> >
> > Those are all forest products, not so much farm products (though honey
> can come from any type of vegetation):
>
> So, do I use landuse=forest or the current landuse=farmland?  What I hear
> is that I must choose between landuse=forest and landuse=residential.  I
> describe "live on family farms in the forest which are partially though not
> necessarily rather forested areas which give rise to many kinds of
> agricultural production, right now, today, flexibly, as we speak."  They
> support families in residential areas simultaneously to whatever seemingly
> singular value I must compress into.  They flexible support vineyards,
> orchards and greenhouse_horticulture.  But, sir, who are you to ask where
> the edge of their residential aspect exists?  I say and property owners say
> (apparently, some renderer authors disagree, and that's certainly OK, I'm
> merely trying to understand it) expound 'the residential semantic' over the
> entire domain.  Anything else, to what we might loosely agree as Americans
> is a "5th amendment taking of property rights by the government."  If that
> sounds political, I guess that's where I say, "OK, diverges from Carto."
> Again, that's OK.  This is about me, Steve, understanding it.
>
> There is such a thing as "family owned 'farm' in the forest which does and
> might give rise to forest products and has some trees where people live in
> small family clusters in residential buildings."  If I need to fit all that
> into a single landuse tag I'd like you to tell me what it is and how it
> renders.  Families and agriculture and human life here on Earth is so much
> more complicated than that.  Thank you.
>
> > "Forest products include materials derived from a forest for commercial
> and personal use such as lumber, paper, and firewood as well as “special
> forest products” such as medicinal herbs, fungi, edible fruits and nuts,
> and other natural products."
> >
> > So, land covered with trees which is used to produce mushrooms,
> truffles, herbs, essential oils, honey, cork, bark, firewood, etc - that's
> forest or woodland, not landuse=farmland.
>
> OK, but people live here, too.  Which landuse value (with farmland out of
> the way), forest or residential?  I shouldn't have to choose.
>
> > > > Yes, the same area may be tree covered and residential at the same
> time.
>
> Of course, there are many of these.  How do we tag them?
>
> > > Yet, Mateusz, you don't say exactly how to tag these.
> >
> > You can just overlap them. Don't worry too much about how OpenStreetMap
> carto renders it, as long as they way you map it makes sense and matches
> reality. Perhaps we can fix the rendering if the current results are
> causing confusion, so that the trees only show when the green background
> shows.
>
> Examples of "how these are properly overlap" are appreciated.
>
> Changing how these layers render now would even-more-confuse.  Let's stick
> to how they do now.
>
> > > a 10 hectare / 25 acre parcel which is 98% trees and 2% house, garage,
> a small clearing
> >
> > Yeah, I would only map the cleared area as landuse=reside

Re: [Talk-us] Heavily-wooded residential polygons

[Joseph Eisenberg]

>  beekeeping, wild mushroom harvesting, herb-crafting for essential oils

Those are all forest products, not so much farm products (though honey can
come from any type of vegetation):

"Forest products include materials derived from a forest for commercial and
personal use such as lumber, paper, and firewood as well as “special forest
products” such as medicinal herbs, fungi, edible fruits and nuts, and other
natural products."

So, land covered with trees which is used to produce mushrooms, truffles,
herbs, essential oils, honey, cork, bark, firewood, etc - that's forest or
woodland, not landuse=farmland.

> > Yes, the same area may be tree covered and residential at the same time.

> Yet, Mateusz, you don't say exactly how to tag these.

You can just overlap them. Don't worry too much about how OpenStreetMap
carto renders it, as long as they way you map it makes sense and matches
reality. Perhaps we can fix the rendering if the current results are
causing confusion, so that the trees only show when the green background
shows.

> a 10 hectare / 25 acre parcel which is 98% trees and 2% house, garage, a
small clearing

Yeah, I would only map the cleared area as landuse=residential in that
case, since the rest of the land is being used to grow trees, not for
residential purposes. While the current owner may not plan to cut firewood
or timber, the next owner might in another 20 or 30 years. Forestry is a
long-term thing.

> 0% row crops, but allows (and actually develops) into orchards,
vineyards, greenhouse_horticulture.

It does not matter what is allowed by the local zoning laws. Don't map
zoning in OpenStreetMap, map what is actually there in reality. So, if they
plant a vineyard, map that as landuse=vineyard. But don't map
landuse=vineyard just because it's allowed to plant a vineyard someday.

– Joseph Eisenberg

On Thu, May 28, 2020 at 3:51 PM stevea  wrote:

> Mateusz Konieczny writes:
> > (quoting stevea)
>  "treed farmland" or "heavily wooded residential" prove slightly
> problematic to OSM tagging.
>
> Then, Mateusz Konieczny answers:
> > Map tree-covered area (landuse=forest) and map farmland
> (landuse=farmland) or residential (landuse=residential).  Yes, the same
> area may be tree covered and residential at the same time.
>
>
> If only it were this simple, it appears not to be.  "Tree covered area"
> can be either landuse=forest (OSM's wiki defines something like a
> half-dozed different conventions on how we actually tag this) OR it can be
> natural=wood.  Very roughly stated, what _I_ do (as I see other California
> and USA-based users doing this — I'm not trying to invent a new tagging
> method) is to map distinctly "timber production" areas as landuse=forest
> and distinctly "appears to be wooded — whether pristine and ancient
> never-cut forest I don't necessarily know — as natural=wood.  That is for
> starters and only attempts to start from a point of "visible trees" (as in
> imagery) while only leaning in the direction of landuse in the aspect of
> landuse=forest being "it is well-known that this is an area which is either
> actively forested, or has the right to have its trees felled" (timber
> permits, owned by a logging company, CAN be cut but maybe are still growing
> to maturity, MIGHT be cut but could also be deeded by owner later on to
> become conservation or land trust protected area...).  The possibilities
> are myriad, but OSM does a "fair to good" job of characterizing these, and
> with only two tags, forest and wood.  This isn't perfect nor is the
> consensus about how we do it, so that aspect alone complicates this
> question, while at least providing SOME stability of understanding the
> complex semantics.
>
> THEN there is the aspect of ALSO-has-a-residential-aspect (or perhaps
> PRIMARILY does).  Clearly, a 10 hectare / 25 acre parcel which is 98% trees
> and 2% house, garage, a small clearing and a driveway for access is
> something quite different than natural=wood (as far as its residential
> landuse goes).  However, it might not be all that different than a
> landuse=forest, ESPECIALLY if the residential land owner also has a timber
> permit to cut trees (possible, though not necessarily common, at least
> around here).
>
> Regarding farmland, this has also been discussed many times, especially
> about Santa Cruz County (see that topic's wiki, the fifth paragraph of the
> "Work to be done in the County" section).  Briefly, misunderstandings
> happen because around here, we have areas which are zoned farmland, (and
> are actually areas of — among other agricultural activities — beekeeping,
> wild mushroom harvesting, herb-crafting for essential oils, other unusual
> but certainly agricultural producti

Re: [Talk-us] Relation template for an honorary/memorial highway?

[Joseph Eisenberg]

All US Interstate Highways are part of the Dwight D. Eisenhower Highway
system, just like they are all part of the Pan-American Highway System.
Neither of these names should be tagged in OpenStreetMap, because they are
not used on signs or by locals.

This information is appropriate for Wikidata and Wikipedia, rather than
OpenStreetMap.

-Joseph

On Tue, May 26, 2020 at 2:43 PM Jack Armstrong 
wrote:

> Sorry. I typed Theodore Roosevelt, but I meant to type, Dwight D.
> Eisenhower Highway. It's the Dwight D. Eisenhower Highway that gives me the
> biggest headaches and longest discussions every time it comes up.
>
> https://www.fhwa.dot.gov/infrastructure/ddehwy.cfm
>
> I thought official_name=* was for country names, but I'm also hesitant to
> use it as I think an interstate highway such as, I-70 would render the
> name, "Dwight D. Eisenhower Highway" on maps when it's not actually used
> by locals nor used on any signage.
>
> I certainly have no desire to spend the time creating relations,
> especially if it's not considered a best practice. I'm just looking for a
> way to avoid so many long discussions (and sometimes arguments) about these
> honorary/memorial names that aren't actually used but were created by some
> obscure congressional bill long ago.
>
> Cheers
>
>
> -Original Message-
> From: Joseph Eisenberg
> Sent: May 26, 2020 2:54 PM
> To: Jack Armstrong
> Cc: Talk us
> Subject: Re: [Talk-us] Relation template for an honorary/memorial highway?
>
> Only real, current features should be mapped, but it's possible to add
> "official names" even if they are not the commonly used name, as long as
> they are documented on signs.
>
> It looks like some of these are historic only:
> https://en.wikipedia.org/wiki/Theodore_Roosevelt_International_Highway -
> historic, no longer exists
>
> And the Pan-American Highway system officially includes all the
> Interstates in the United States, but has no signage. So there is not an
> appropriate way to map this in OpenStreetMap:
> https://en.wikipedia.org/wiki/Pan-American_Highway#Contiguous_48_states_of_the_United_States
>
> But these can probably be tagged as "official_name=Ronald Reagan Highway":
> https://en.wikipedia.org/wiki/Ronald_Reagan_Highway
>
> – Joseph Eisenberg
>
> On Tue, May 26, 2020 at 12:15 PM Jack Armstrong 
> wrote:
> >
> > More than once in the past, users have attempted to “name” highways in
> Colorado as the “CanAm Highway”, the “Pan-American Highway”, the “Ronald
> Reagan Memorial Highway” and the “Theodore Roosevelt International
> Highway”, to name a few. There are other honorary/memorial highway
> designations in the area.
> >
> >
> > In order to satisfy persons who want to map these and other memorial
> highways that aren’t actually named “on the ground” here, I’m thinking
> relations might be created. This way, when this situation undoubtedly comes
> up again, I can point the user to the relation and more easily resolve any
> conflicts.
> >
> >
> > Any suggestions as to the relation template I should use? I looked at
> the interstate highway relation wiki and it doesn’t seem to be quite right.
> For example, it requires a ref - number only.
> >
> >
> > I suppose, where appropriate, a different relation should be created for
> each state the memorial highway passes through? Which network relation or
> super relation should these memorial route relations be tied into?
> >
> >
> > Any feedback is welcome. Thanks :)
> >
> >
> >
> >
> > ___
> > Talk-us mailing list
> > Talk-us@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-us
>
>
>
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Relation template for an honorary/memorial highway?

[Joseph Eisenberg]

Only real, current features should be mapped, but it's possible to add
"official names" even if they are not the commonly used name, as long as
they are documented on signs.

It looks like some of these are historic only:
https://en.wikipedia.org/wiki/Theodore_Roosevelt_International_Highway -
historic, no longer exists

And the Pan-American Highway system officially includes all the Interstates
in the United States, but has no signage. So there is not an appropriate
way to map this in OpenStreetMap:
https://en.wikipedia.org/wiki/Pan-American_Highway#Contiguous_48_states_of_the_United_States

But these can probably be tagged as "official_name=Ronald Reagan Highway":
https://en.wikipedia.org/wiki/Ronald_Reagan_Highway

– Joseph Eisenberg

On Tue, May 26, 2020 at 12:15 PM Jack Armstrong 
wrote:
>
> More than once in the past, users have attempted to “name” highways in
Colorado as the “CanAm Highway”, the “Pan-American Highway”, the “Ronald
Reagan Memorial Highway” and the “Theodore Roosevelt International
Highway”, to name a few. There are other honorary/memorial highway
designations in the area.
>
>
> In order to satisfy persons who want to map these and other memorial
highways that aren’t actually named “on the ground” here, I’m thinking
relations might be created. This way, when this situation undoubtedly comes
up again, I can point the user to the relation and more easily resolve any
conflicts.
>
>
> Any suggestions as to the relation template I should use? I looked at the
interstate highway relation wiki and it doesn’t seem to be quite right. For
example, it requires a ref - number only.
>
>
> I suppose, where appropriate, a different relation should be created for
each state the memorial highway passes through? Which network relation or
super relation should these memorial route relations be tied into?
>
>
> Any feedback is welcome. Thanks :)
>
>
>
>
> ___
> 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] admin_level and COGs, MPOs, SPDs, Home Rule

[Joseph Eisenberg]

I also think that it makes sense to have counties as admin_level=6 in
Connecticut and Rhode Island, if local people still know their counties and
the governments still recognize them for geographic, statistical and some
other legal purposes.

-- Joseph Eisenberg

On Fri, May 15, 2020 at 1:42 PM Frederik Ramm  wrote:

> (3d attempt, apologies if you should get this several times)
>
> Hi,
>
> I am tempted to revert stevea's removal of the admin_level=6 from
> counties (where this was in place for the last 10 years or so, eg
> https://www.openstreetmap.org/relation/1839542/history) until a
> consensus is found that they should actually be removed.
>
> It is clear that there is a need for discussion, and I feel that such a
> discussion should take place *before* a change is made and not *after*.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> 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: [OSM-talk] Relation: 1204546, polygon error.

[Joseph Eisenberg]

Looking at
https://www.openstreetmap.org/relation/1204546#map=13/29.6738/-81.1861 - I
don't see any visual problems currently. What are you seeing?

The only tagging problem I see is that the coastline here is not tagged
properly. This whole area looks like a salt water lagoon system, which
should be mapped with coastline, since it is marine salt-water.

-- Joseph Eisenberg

On Thu, May 14, 2020 at 7:57 PM 80hnhtv4agou--- via talk <
talk@openstreetmap.org> wrote:

> has a ghosts water multipolygon,
>
> that keep moving over land.
>
> https://wiki.openstreetmap.org/wiki/Nominatim/Polygons
>
> i can not see the break, and every in the middle is a relation ship.
>
>
>
>
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] OpenStreetMap Carto release v5.2.0

[Joseph Eisenberg]

Dear all,

Today, v5.2.0 of the OpenStreetMap Carto stylesheet (the default stylesheet
on the OSM website) has been released. Once changes are deployed on the
openstreetmap.org it will take couple of days before all tiles show the new
rendering.

Changes include:

- Add rendering for man_made=goods_conveyor (#4102)
- Tunnel style rendering of waterway=canal with tunnel=flooded (#4087)
- Remove rendering of residential, unclassified, cycleway, path, track
highway areas (#4096)
- Remove rendering of protect_class = 7, 24, 97, 98, 99
boundary=protected_area features (#4113)
- Move place=square to amenity-points layer with placenames text style from
z17 (#4085)
- Change wetland pattern initial zoom level back to z10 (#4094)
- Render bare_rock pattern from z13, same as shingle and scree (#4072)
- Restore admin-text rendering for admin_level 3 to 5 (#4126)
- Move aerialways and amenity-line layers text labels to text-line layer
(#4107)
- Fix python3 installation for Docker (#4125)

Thanks to all the contributors for this release, including @owahltinez
(Oscar Wahltinez), a new contributor.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v5.1.0...v5.2.0

As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Remove Wikidata parameter from Infobox on wiki (ValueDescription, KeyDescription boxes)

[Joseph Eisenberg]

I have removed the wikidata parameter from the Description template and
it's related documentation page.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-us] How to map snowmobile trails in US?

[Joseph Eisenberg]

Winter-only snowmobile routes are mapped if they are signed. Create a route
relation with type=route + route=snowmobile (used 141 times) - see
https://wiki.openstreetmap.org/wiki/Tag%3Aroute%3Dsnowmobile

Please only use highway=track when there is an forestry or agricultural
road / track which is passable by 2-track vehicles such as farm tractors,
logging trucks, or 4wd cars.

-- Joseph Eisenberg

(You might try the Tagging mailing list for questions about how to tag
something: tagg...@openstreetmap.org)

On Thu, May 7, 2020 at 8:43 AM Kevin Broderick 
wrote:

> Ideally, I'd say that most snowmobile routes should be relations, not
> ways. At least in the places I'm familiar with (New England and Montana), a
> significant portion of the snowmobile trail network overlaps with seasonal
> roads that are open to wheeled traffic in some conditions. Having the
> summer ground truth mapped accurately is hugely helpful if you're poking
> around in the summer, whether it be hiking, biking, riding an on/off-road
> motorcycle, etc; as you noted, some snowmachine trails are virtually
> invisible in the summer and may even be impassable (I'm familiar with some
> spots in Vermont where the snowmachine trails transit across swamp or
> marshland once it's frozen—not something you want to try to cross on foot
> or wheeled vehicle).
>
> Around here, there's also the side issue of someone having mapped one of
> the ITS routes as a track for a long distance, when it actually should be a
> series of ways with different data, as some parts are well-maintained
> gravel roads in the summer, others are less-well-maintained, some are
> public ways and others aren't.
>
> To answer the question about sections that specifically cross fields: I'd
> still be tempted to tag that as highway=track, with appropriate access and
> surface tags. I'm not sure it's the best way to do it, but I can't come up
> with a better way, and the track in question would likely be passable with
> permission and the right vehicle.
>
> As for sections that cross [frozen] marshes, or other areas that aren't
> passable when the ground is thawed, I don't know. Maybe there is a use case
> for "highway=frozen" or something similar, as ice_road is applied to
> another way, and none of the highway= values with which  I'm familiar would
> make sense.
>
> On Thu, May 7, 2020 at 10:41 AM Bob Gambrel  wrote:
>
>> Am newby to talk-us. This may have been discussed in the past but not
>> handy with searching archives yet.
>>
>> In Minnesota I have seen snowmobile trails mapped in OSM as follows:
>>
>> highway=track
>> snowmobile=designated
>> surface=unpaved
>>
>> In both aerial photos and observation on the ground, there is almost
>> always no track visible. In the winter, with snow cover, the location of
>> the track is visible because it is compacted by snowmobiles. In the spring
>> there might be some evidence in areas with grasses that would have been
>> tamped down by the snowmobiles.
>>
>> Question: Is this the right way to map snowmobile trails? The thing that
>> concerns me, of course, is the use of "track" because of it is not apparent
>> most of the time.
>>
>> Another question: is there a forum or expert group or something that
>> discusses this? I would like to join that conversation if there is  one
>> going on.
>>
>> I think it is a good idea to map these trails. It seems there maybe
>> should be another type of highway? Something like: "not visible on the
>> ground most of the year". Note that ice_road=yes is not appropriate here
>> (in most cases) as (in most cases) these trails are not on frozen water
>> bodies.
>>
>> As further info, where I was able to observe there are a number of signs
>> posted such as stop signs, caution signs, etc. So there clearly is
>> government involvement.
>>
>> Any thoughts?
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>
>
> --
> Kevin Broderick
> k...@kevinbroderick.com
> ___
> 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

[OSM-talk] Remove Wikidata parameter from Infobox on wiki (ValueDescription, KeyDescription boxes)

[Joseph Eisenberg]

I propose removing the "wikidata=" parameter from the descriptions of keys
and tags on the OpenStreetMap wiki. See discussion:

https://wiki.openstreetmap.org/wiki/Template_talk:ValueDescription#Wikidata

"While it is sometimes possible to state that all OSM elements with that
tag are an instance of some Wikidata item, it is not possible in other
situations. For example, roads with bridge=yes crossing a man_made=bridge
are not instances of "bridge". Furthermore, a lot of OSM tags don't
represent an instance relationship with some class of objects at all, but
are properties instead. So I doubt that mapping Wikidata onto OSM tags in
that manner is feasible. --Tordanik 21:47, 1 September 2014 (UTC)"

"I don't think the "Wikidata" link adds anything useful for OSM mappers and
I would be in favour of dropping it. Also, if there is no Wikidata link
set, then currently the template displays a "search in Wikidata..." link
which gives the whole "linked data" religion unnecessary prominence. The
template has many optional parameters, and "wikidata" is the only parameter
where, when it is missing, Wiki users are nudged in the direction of
researching and adding it. This makes it look as if adding the "wikidata"
parameter was a more valuable use of an editor's time than completing other
missing bits of information. This is a value judgement that I oppose.
--Frederik Ramm 16:02, 8 November 2018 (UTC)"

"Now we have our own Wikibase there’s another problem. The Wikidata link
has a database link (Q number) that is different from the Q number in our
own Wikibase instance. The WMF developers were very un-keen on Yuri’s
suggestion of us using a different prefix letter to distinguish the two.
Getting rid of the Wikidata parameter would solve this.--Andrew (talk)
06:26, 9 November 2018 (UTC)"

I've also noted that often the links are wrong, because a tag like
"craft=*" is not the same as the wikidata definition of "crafts". You would
need to link to several wikidata concepts to describe one OpenStreetMap tag
in that case.

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

Re: [OSM-talk] Let's talk Attribution

[Joseph Eisenberg]

The source linked, for village boundaries in India, requires printed
attribution on the map or a link for online maps:


“Attribute

Please use the following lines to attribute the maps if you use in your
work. You could link instead of printing the URLs in case of web projects.

Villages Maps Provided by Indian Village Boundaries Project [
http://projects.datameet.org/indian_village_boundaries/] by Data{Meet}. Its
made available under the Open Database License (ODbL)[
http://opendatacommons.org/licenses/odbl/].”


So that source of data also expects visible attribution from map makers.


— Joseph Eisenberg

On Thu, Apr 30, 2020 at 8:20 AM Tom Lee via talk 
wrote:

> At the risk of repeating others' words, I strongly encourage participants
> in this conversation to review the draft attribution guideline (
> https://wiki.openstreetmap.org/wiki/Draft_Attribution_Guideline) and
> previous conversations regarding attribution on this list. It would be hard
> to overstate the depth of experience that the legal working group has
> regarding these issues, so it has been surprising to me to see their
> perspective receive so little attention.
>
> Because I know not everyone will dig back into those listserv archives, I
> want to highlight one point that has been previously made: OpenStreetMap
> itself does not meet the ODbL attribution standards that are being
> presented as obvious by some parties to this conversation. This applies not
> only to several ODbL data source attributions present on
> https://wiki.openstreetmap.org/wiki/Contributors (but not on the map) but
> also to the many ODbL data sources that can be found under
> https://wiki.openstreetmap.org/wiki/Category:Data_sources (note that not
> all of these sources may be in use; this part of the wiki is not
> sufficiently organized to be sure).
>
> OpenStreetMap is by far the most significant project using ODbL, and when
> geodata is published under ODbL terms (as frequently happens in France[1])
> or when it is adopted by a geodata project (such as Datameet's work on
> Indian village boundaries[2]
> <http://projects.datameet.org/indian_village_boundaries/>) it is
> typically with the intent of making the data useful to OpenStreetMap. It
> doesn't seem plausible that the volunteers working on those Indian village
> boundaries expect their preferred attribution[3] to be part of the UI that
> greets any OSM user. This suggests to me that volunteers' attribution
> expectations are not as uniform as has been suggested in this thread.
>
> Reviewing the diversity of attribution policies found under
> https://wiki.openstreetmap.org/wiki/Category:Data_sources might prove
> more illuminating than rehashing our understanding of Google's terms and
> what they might or might not do for enterprise customers. A review of the
> many custom government licenses and amended CC-BY licenses that OSM
> volunteers have added to those wiki pages will show a variety of approaches
> to attribution, almost none of which meet the level of obtrusiveness
> proposed at various times in this thread. Obviously, the ODbL is its own
> beast; as others have noted, the practices of the rest of the open mapping
> world and commercial mapping industry need not bind it. But I do think they
> are a useful signal as we consider what "reasonable" could mean.
>
> [1]
> https://wiki.openstreetmap.org/wiki/FR:Sources_de_donn%C3%A9es_potentielles/France
> [2] http://projects.datameet.org/indian_village_boundaries/
> [3] "Villages Maps Provided by Indian Village Boundaries Project [
> http://projects.datameet.org/indian_village_boundaries/] by Data{Meet}.
> Its made available under the Open Database License (ODbL)[
> http://opendatacommons.org/licenses/odbl/];
> ___
> 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] Let's talk Attribution

[Joseph Eisenberg]

It’s a database technically, but it’s a database purpose-built for making
maps. Hence the name OpenStreetMap.

The attribution goes on the map.

This is not a difficult requirement to meet.

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

[OSM-talk] OpenStreetMap Carto release v5.1.0

[Joseph Eisenberg]

Dear all,

Today, v5.1.0 of the OpenStreetMap Carto stylesheet (the default stylesheet
on the OSM website) has been released. Once changes are deployed
on the openstreetmap.org it will take couple of days before all tiles
show the new rendering.

Changes include:

- Remove way_area filtering for low zoom water (#4060)
- Move small amenities to z18 (#4044)
- Rework admin-boundaries to show admin_level=5/6/7 sooner but
admin_level=10 later (#4100)
- Add rendering for addr:flats (#4082) - by @richlv
- Add rendering for man_made=pipeline ways (#4070)
- Add line rendering plus name labels for ridges and aretes (#3767)
- Add rendering for landuse=salt_pond (#4059)
- Remove power=sub_station/station rendering, add power=plant fill color (#4088)
- Remove rendering of residential/unclassified, track, foot/cycleway
highway areas (#4096)
- Remove icon for shop=ice_cream (#4093)
- Remove information=tactile_model rendering (#4086)
- Remove duplicate selection of natural = cave_entrance, peak,
volcano, saddle (#4068)
- Move natural=spring back to amenity-points layer (#4069)
- Change quarry outline to 10% darkened quarry color (#4063)
- Change bridge-text way_pixels minimum and maximum (#4066)
- Update Dockerfile keyserver URL for osmadmins PPA (#4079) - by @volcan01010
- Code clean-ups (#4080, #4081, #4083, #4099)

Thanks to all the contributors for this release, including new 2
contributors: @richlv and @volcan01010

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v5.0.0...v5.1.0

As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues

-- Joseph Eisenberg

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

Re: [OSM-talk] Question regarding public_transport=stop_position

[Joseph Eisenberg]

This sort of question might be more appropriate for the "Tagging" or
public transport mailing lists.

But yes, there is no need to add public_transport=stop_position nodes
on a highway or railway to show where a train or bus stops, if there
is a highway=bus_stop or railway=platform which is mapped right next
to the highway or railway, and it is clear that the bus or train stops
at the closest point of the highway to the bus stop or platform.

Since most bus stops do not have stop_position nodes, any public
transit routing application will need to be able to deal with this
situation.

However, this issue is controversial, and I'm not surprised that you
are finding conflict when removing the nodes. Generally, I would
ignore them rather than taking the time to delete them, unless they
are make it difficult to edit other features.

There is a long, complex history of how public transit features are
tagged in OpenStreetMap. From what I've read, originally almost all
bus stops were tagged with highway=bus_stop nodes next to the highway,
at the location of the bus stop sign, but railway=tram_stop nodes were
mapped directly on the railway way, with the platform sometimes mapped
separately (if there is a platform - sometimes a tram just stops in
the middle of the street and passengers have to walk across to it from
the sidewalk).

This bothered some mappers who wanted to import public transit data
from their local database, which had all of the nodes mapped on the
railway or highway way. Some started mapped highway=bus_stop with a
node on the highway way, but this lost the information about where the
passengers actually should wait. So, someone who wanted nodes on the
ways proposed public_transport=stop_position for every highway and
railway position where a train or bus stops, and
public_transport=platform as a synonym for highway=bus_stop or
railway=platform.

While some mappers accepted that proposal and started mapping 2 nodes
for every single train stop and platform, most bus stops have
continued to be mapped as only a highway=bus_stop node, and
public_transport=stop_position is rarely used for buses. Generally the
public_transport tags are only used in addition to the original tags.

So it's correct to say that the public_transport tags are almost never
needed. In particular, public_transport=stop_position is very rarely
useful.

(In very rare cases there might be a service road which loops around
behind a bus stop and it might be unclear if the bus stops on the
service road or the main highway - but this would very rarely matter
for public transit riders and general map users. It might matter for
bus drivers, but they should use a separate database which includes
this information.)

-- Joseph Eisenberg


On 4/3/20, Jack Armstrong  wrote:
> The wiki for public_transport=stop_position states, “If the stop on the
> public transport route has a defined platform, there is no benefit in adding
> public_transport=stop_position. In these cases, do not use
> public_transport=stop_position to avoid duplication of information and
> confusion.” You can see the wiki page here:
> https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_position
>
>
> The conversations on the wiki discussion page seem to agree that
> stop_position is not needed where a defined platform exists.
>
>
> I’m mapping railway and light-rail in a metropolitan area. Following the
> above wiki statement, I have removed stop positions where “defined
> platforms” are located. My goal is to follow the wiki, to…the…letter.
> Honestly, I don’t have a preference as to which manner railways are mapped.
>
>
> Recently, another user has contacted me. This user is unhappy that the stop
> positions have been removed. I’ve explained that the wiki states, “…do not
> use public_transport=stop_position to avoid duplication of information and
> confusion.”
>
>
> The user who sent me the complaint has directed me to this diagram:
>
> https://wiki.openstreetmap.org/wiki/Railway_stations#Overview
>
>
> Is the wiki correct? Are we not using stop_position where a defined platform
> exists? If this is incorrect, should the wiki be changed?
>
>
> Again, my only goal is map correctly,
>
>
> Thanks :)
>
>
>
>
>
>

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

[OSM-talk] New status for keys/tags in the wiki: "import" for tags that are only imported from an external database

[Joseph Eisenberg]

After the discussion, the status "import" should be limited to tags
that are clearly imported from external sources. Common examples are
external references, IDs, source tags, and specialized import-only
tags (e.g. "tiger:*"). Most of these don't have a wiki page.

I've added status=import and tagged a few keys which are documented:

https://wiki.openstreetmap.org/wiki/Category:Key_descriptions_with_status_%22import%22

Examples:

Key:gnis:feature_id
Key:import_uuid
Key:ref:bag
Key:ref:FR:MemorialGenWeb
Key:ref:ruian
Key:ref:sandre
Key:tiger
Tag:source:addr=GURS

All of these are clearly from imports only (e.g Key:tiger,
Key:import_uuid) or are only used as an external reference to another
database, and cannot be obtained by visiting the feature in person.

If I've made any mistakes, by including a ref:* which is actually used
on physical signs or obects, rather than only in another website or
database, please make corrections.

Also see update of https://wiki.openstreetmap.org/wiki/Approval_status
with this value.

-- Joseph Eisenberg

On 3/17/20, Joseph Eisenberg  wrote:
> I would like to add a new status to
> https://wiki.openstreetmap.org/wiki/Approval_status and to Tag and Key
> pages in the wiki
>
> The value "import" would be used for tags that were used in a large
> import, but are no longer commonly being added.
>
> These tags often have high numbers in the database but have not been
> accepted by the community and rarely are being used by mappers (in
> some cases they have never been added, except by the import), so they
> should not have the status "in use", and they were never proposed in
> most cases.
>
> Using "import" as the status would make it clear that these tags are
> not "de facto", "in use" or "approved", and would be more specific and
> clear than "unspecified".
>
> Examples:
> https://wiki.openstreetmap.org/wiki/Key:tiger (tiger:county=*,
> tiger:tlid=* and tiger:upload_uuid=* etc)
> https://wiki.openstreetmap.org/wiki/Key:gnis:feature_id
> https://wiki.openstreetmap.org/wiki/Item:Q1607 - nhd-shp:fdate
> https://wiki.openstreetmap.org/wiki/Item:Q1606 - nhd-shp:fcode
>
> -- Joseph Eisenberg
>

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

Re: [OSM-talk] [OSM-dev] OpenStreetMap Carto release v5.0.0

[Joseph Eisenberg]

All style users who upgrade to v5.0.0 should re-import the rendering
database so that the changes to lua transformations will take effect.

Because of this requirement, it may take longer than usual for this
version to be implemented by the rendering servers for the "Standard"
map tile layer at openstreetmap.org

On 3/19/20, Paul Norman via dev  wrote:
> Dear all,
>
> Today, v5.0.0 of the OpenStreetMap Carto stylesheet (the default
> stylesheet on the OSM website) has been released. Once changes are deployed
> on the openstreetmap.org it will take couple of days before all tiles
> show the new rendering.
>
> Changes include
> - An update to Lua tag transforms, setting line vs polygon decisions
>    for new tags
>
> - Added upper way_area limits to most features using ST_PointOnSurface
>    to avoid performance problems from large polygons
>
> - Moved MSS files into their own directory
>
> - Removed rendering of power=cable features
>
> - Removed overlay pattern for natural=sand
>
> - Reduced landcover fading at mid-low zoom levels
>
> - Removed rendering of barrier=kerb
>
> Thanks to all the contributors for this release.
>
> For a full list of commits, see
> https://github.com/gravitystorm/openstreetmap-carto/compare/v4.25.0...v5.0.0
>
> As always, we welcome any bug reports at
> https://github.com/gravitystorm/openstreetmap-carto/issues
>
>
> ___
> dev mailing list
> d...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev
>

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

Re: [OSM-talk] Proposed new status for tags in the wiki: "import" for undiscussed tags that were only used by an import

[Joseph Eisenberg]

> I don't think that swiching from addr:* to object:* on these objects is 
> correctly described by the term "mechanical edit".

Yes it was a mechanic/automated edit, because you switched all the tags at once

Not all mechanical edits are bad:
https://wiki.openstreetmap.org/wiki/What%27s_the_problem_with_mechanical_edits%3F

It sounds like you followed the Automated Edits code of conduct by
discussing the change with the local community first, and you mainly
edited objects that you had personally helped to map, so that is a
good example of an automated edit which was done according to best
practices:
https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct

-- Joseph Eisenberg

On 3/18/20, Harald Schwarz  wrote:
> Hello,
>
> the creation of the object:* tagging was the result of many remarks and
> disscussions. Most people agreed that the addr:* tag should be used
> only for buildings, shps, offices, etc.
>
> I thought that there was a need for an alternative addresing scheme that
> could be used without conflicting with the addr:* scheme.
> That was when I starteted to use the object:* scheme for the things I tagged
> in OSM.
>
> As I'm not only interrested in gas lamps but also in history culture and art
> I started to use this scheme for memorials and urban artwork.
> I conviced some people in my community to switch to this scheme and now more
> and more people use this scheme.
>
> I added a lot of Stolpersteine (memorial:type=stolperstein) and urban
> artwork (tourism=artwork) to the OSM database. All of them I visited
> personly and photos of this objects can be found on wikimedia commons.
>
> I have a very personal relation to these obects, visiting them in real
> world, during hot or cold weather, storing information about them
> to OSM in long concentrated sessions. I don't think that swiching from
> addr:* to object:* on these objects is correctly described by the
> term "mechanical edit".
>
> Mechanical edits are problematic in OSM as there might be change on
> something that doesn't exist anymore or needs a new survey at the place in
> real world.
> As I walk all this object from time to time, veryfing they still exist, I
> think that it is not ok to call my changes mechanical edits in the normal
> OSM sense.
>
> Friendly Greetings
>   Harald Schwarz
>   black_bike
>
>
>> Gesendet: Mittwoch, 18. März 2020 um 02:03 Uhr
>> Von: "Joseph Eisenberg" 
>> An: "Harald Schwarz" 
>> Betreff: Re: Re: [OSM-talk] Proposed new status for tags in the wiki:
>> "import" for undiscussed tags that were only used by an import
>>
>> Thank you for the information, Harald.
>>
>> > The peak in the graph, that you think indicates an import, is the result
>> > of switching fom the addr:*-style to the object:*-style.
>>
>> So it was not an import, but rather a mechanical edit. I will update
>> the object: page with this info.
>>
>> Do you know if a mechanical edit was also done for historic=memorial
>> features (with object:housenumber etc) around that time?
>>
>> -- Joseph Eisenberg
>>
>> On 3/18/20, Harald Schwarz  wrote:
>> > Dear Joseph, dear readers of this list,
>> >
>> > as you mention the street lamps of Düsseldorf here and thinking that
>> > they
>> > were an import to the OSM-database,
>> > I can tell you that this was not the case.
>> >
>> > Many of he streets of Düsseldorf, city of about 600_000 inhabitants,
>> > capital
>> > of Northrhine-Westfalia, Germany are lit by gaslight.
>> > About 15_000 gas lamps spent their glooming light every night. Each of
>> > this
>> > lamps has found it's way into the OSM database
>> > and even the status of streets lit by gaslight can be found in OSM.
>> >
>> > But this was not done by an import. It was a process, lasting many
>> > years,
>> > walking all the streets, stopping at every
>> > single gas lamp, taking photos and gps coordinates, later manualy
>> > storing
>> > the data to osm.
>> > The peak in the graph, that you think indicates an import, is the result
>> > of
>> > switching fom the addr:*-style to the object:*-style.
>> >
>> > Infos about the Düsseldorf Gaslight you can find in the OSM-Wiki under:
>> > https://wiki.openstreetmap.org/wiki/D%C3%BCsseldorf/Projekte/Gaslaternen
>> > You can watch the talk I gave at FOSSGIS 2019, Dresden :
>> > https://media.ccc.de/v/fossgis2019-556-erfassung-der-dsseldorfer-gasbeleuchtung
>> > .
>> >
>> > Mapping the gas lamps with 

Re: [OSM-talk] Proposed new status for tags in the wiki: "import" for undiscussed tags that were only used by an import

[Joseph Eisenberg]

Unlike some of those who responded, I was not intending this status to
be a "mark of shame", but rather informative.

As mentioned, some imported tags like "gnis:feature_id=*" are useful
to keep the Openstreetmap database object directly linked to an object
in an external database.

That's why I am not suggesting the use of "deprecated" or "obsolete",
since these tags should not necessarily be removed.

The main reason to mark them is so that mappers and database users
will understand where the tag came from, and it may suggest that
mappers will not want to add these tags to objects in the future,
unless they are also importing features from the same source.

Besides the tags mentioned above, I was thinking about tags like
"object:postcode=" and "object:housenumber" - this tag is only used in
Germany on "highway=street_lamp" features which appear to have been
imported mostly in 2015: http://wiki.openstreetmap.org/wiki/Key:object
and see taghistory:
https://taghistory.raifer.tech/#***/object:postcode/ and

So, though the usage numbers are moderately high, it is helpful to
know that these tags are not really being used, except in that
particular context. Apparently it makes sense in the context of the
addressing system there, at least according to the mappers who
imported the objects.

If a tag which was first used in an imported then becomes popular and
used frequently by. mappers for new or updated features, then it could
change to "in use" or even "de facto", just like a "draft" or
"proposed" tag can change status due to usage over time.

So, just like the status "draft", the status "import" would be a hint
for mappers and database users, but would not suggest that the tag
needs to be removed, and it might change status in the future based on
use by mappers.

-- Joseph Eisenberg

On 3/18/20, Jmapb  wrote:
> On 3/17/2020 10:52 AM, Wayne Emerson, Jr. via talk wrote:
>> However, among your examples you cite "gnis:feature_id=*" The wiki
>> page for this key notes:
>> "Unlike other imported tags such as gnis:created=* and
>> gnis:import_uuid=*, gnis:feature_id=* is meaningful beyond the import.
>> In fact, some mappers actively add gnis:feature_id=* to features to
>> cite a verifiable source for the POI's existence or its name."
>
> Agree with clemency for gnis:feature_id -- it's handy to be able to
> crossreference features with the GNIS database, which you can search by
> feature id here: https://geonames.usgs.gov/apex/f?p=138:1:0:
>
> J
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>

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

[OSM-talk] Proposed new status for tags in the wiki: "import" for undiscussed tags that were only used by an import

[Joseph Eisenberg]

I would like to add a new status to
https://wiki.openstreetmap.org/wiki/Approval_status and to Tag and Key
pages in the wiki

The value "import" would be used for tags that were used in a large
import, but are no longer commonly being added.

These tags often have high numbers in the database but have not been
accepted by the community and rarely are being used by mappers (in
some cases they have never been added, except by the import), so they
should not have the status "in use", and they were never proposed in
most cases.

Using "import" as the status would make it clear that these tags are
not "de facto", "in use" or "approved", and would be more specific and
clear than "unspecified".

Examples:
https://wiki.openstreetmap.org/wiki/Key:tiger (tiger:county=*,
tiger:tlid=* and tiger:upload_uuid=* etc)
https://wiki.openstreetmap.org/wiki/Key:gnis:feature_id
https://wiki.openstreetmap.org/wiki/Item:Q1607 - nhd-shp:fdate
https://wiki.openstreetmap.org/wiki/Item:Q1606 - nhd-shp:fcode

-- Joseph Eisenberg

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

Re: [Talk-us] Updating opening_hours for COVID-19.

[Joseph Eisenberg]

That's great, if you are committed to going back and changing all the
opening_hours again in a month or two.

But it could be a bad idea in the long term if there is no follow-up
to return the hours to the regular ones afterward.

- Joseph Eisenberg

On 3/14/20, Eric Christensen via Talk-us  wrote:
> I've been updating the opening_hours for businesses and services as I
> hear about them closing or changing their hours of operation for
> COVID-19.  I'm also adding a note in the description with any
> information the source is providing.
>
> Seems like a good idea to keep people updated to what's open and what's not.
>
> I wonder if anyone else is also doing this as well?
>
> --Eric
>
>
> ___
> 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: [OSM-talk] Announcing Daylight Map Distribution

[Joseph Eisenberg]

My understanding is that the common way to describe armchair mapping,
based on aerial imagery, is to identify the imagery source. So I often
write:

Changeset Comment: "Added and adjusted streams and rivers near Oksibil
with ESRI"
Changeset Source: "Esri world imagery"

This makes it clear that I used Esri imagery to map the streams and
rivers, right?

- Joseph Eisenberg

On 3/10/20, Sören Reinecke via talk  wrote:
> Hey
>
> some ideas about identifying such changes:
>
>
> Example changeset comment where a mapper did armchair mapping:
> Data updated, added amenity=restaurant
> #armchair
>
> In addition if the mapper works for a company:
> #
> e.g. #facebook
> #amazon
> #microsoft
> #apple
>
> Example changeset comment where a mapper did a survey and added data as
> (s)he saw it (from the ground):
> #survey
>
>
>
> This way we can organize our changes and Facebook and other companies and
> the community as well know how to validate and can distinguish changesets
> from another. I could create a wikipage where we think about this "changeset
> governance"
>
> Cheers
>
> Sören Reinecke alias Valor Naram
>
>
>  Original Message 
> Subject: Re: [OSM-talk] Announcing Daylight Map Distribution
> From: Volker Schmidt
> To: talk@openstreetmap.org
> CC:
>
>
>>
>>
>>> Fixing stuff in OSM purely from imagery may not be good.
>>>
>>> A local mapper who sees something may add it before any satellite imagery
>>> has it.
>>>
>>> If you then 'fix' this back to the satellite imagery you will have
>>> committed an error,
>>> and that error may dissuade our most important resource from ever making
>>> any further changes- the local mapper.
>>>
>>> Be very careful!
>>
>>
>> I second this last line !
>>
>> I am observing an influx of mixed-quality remote edits from Amazon
>> Logistics in my area.
>> I expect this Facebook operation to produce much more changes or potential
>> changes (=suspected errors).
>> What we need for both cases and similar ones in the future is a way of
>> being able to identify such changes, which by their nature will be
>> armchair-mapping efforts.
>> I do not have a specific proposal, but I would appreciate a tool that
>> helps me, as local mapper,  find these edits, and, more importantly we
>> need a new approach to organise digesting these massive distributed
>> armchair-mapping interventions on OSM data.
>> I don't realistically think that banning these activities is good for OSM.
>> Not dealing in a systematic way with it at all presents, however, a big
>> risk of deteriorating the map for two reasons:
>> (1) bad armchair edits by Amazon and Facebook (and others)
>> (2) demotivating non-armchair mappers
>>
>> I repeat I do not have a proposal how to handle that. My main concern is
>> that the required work for locally checking even only those edits that
>> need checking (I am assuming that at least FB has good algorithms to sort
>> out the dead-certain corrections beforehand. I am more sceptical with
>> Amazon's changing local access tagging to, essentially, "yes" everywhere
>> they have delivered something by delivery van. I came across a good number
>> of them, and in most cases they were at least dubious)
>>
>> Volker
>> (Padova, Italy)
>

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

Re: [OSM-talk] Announcing Daylight Map Distribution

[Joseph Eisenberg]

Interesting! That sounds like a huge amount of work, if you are
validating every changeset in the globe, though so far there is no
schedule to release this frequently.

Thank you for following the Open Database license by releasing this to
the public.

Is facebook planning to create new planet files like this on a
frequent basis, for internal use? If so, those should be released to
the public on a regular schedule, if I understand the ODbL correctly.

Can I confirm that facebook is editing Openstreetmap data to fix the
errors which are found? Or is this only happening in some cases?

The diary post gave links that explain how this was made (both from
September 2019):
 - https://engineering.fb.com/ml-applications/mars/ "MaRS: How
Facebook keeps maps current and accurate"

"We calculate the absolute diff between the two OSM versions (from
option 1 above).
We then split this diff into a set of LoChas that can be individually
applied (from option 2)."
...
"At a high level, a map change is vetted by a reviewer,"

 - 
https://2019.stateofthemap.us/program/sun/keepin-it-fresh-and-good-continuous-ingestion-of-osm-data-at-facebook.html
"“Keepin’ it fresh (and good)!” - Continuous Ingestion of OSM Data at
Facebook":

This is a video presentation, so I haven't seen it all, but the
abstract says: "we have created an automated ingestion and integrity
framework for OSM data that allows us to selectively update parts of
the map instead of doing a full snapshot change all at once.

"Decomposing a large set of changes in this way gives us the
flexibility to rapidly ingest our own additions to the map, focus on
geographical areas of importance to downstream products, and allows us
to quickly apply hotfixes whenever egregious problems do arise.

"With millions of tiny changes happening every week, we have created a
system that is built on per-feature approval and preprocessing, that
allows us to ingest changes at scale, while creating rules to
automatically process logical changesets and enforce integrity
constraints (e.g. anti-vandalism, anti-profanity etc.).

"Due to the contextual nature of some of the changes in OpenStreetMap,
the system combines Human Approval, necessary for highly visible
features such as names of large administrative areas, with Automated
AI/ML-based approval: for example, using computer vision techniques to
reconcile newly created features against satellite imagery ground
truth, or applying NLP techniques to determine whether other
user-visible string changes are sensible and valid. These components
are combined to create a continuous ingest-validate-deploy cycle for
OSM map data."

Lot's of buzz words there! But it sounds like it is a combination of
computer algorithms and human checking for vandalism and errors.

- Joseph Eisenberg

On 3/10/20, Michal Migurski  wrote:
> Hi everyone,
>
> I’m writing to let you know about a new OpenStreetMap project Facebook just
> released. It’s called Daylight Map Distribution. Daylight is a complete,
> downloadable preview of OpenStreetMap data we plan to start using in a
> number of our public maps:
>
>   https://www.openstreetmap.org/user/migurski/diary/392416
>
> Facebook uses maps to let our users find friends, businesses, groups and
> more. OpenStreetMap (OSM) has a substantial global footprint of map data
> built and maintained by a dedicated community of global mappers and it’s a
> natural choice for us. Every day, OSM receives millions of contributions
> from the community. Some of these contributions may have intentional and
> unintentional edits that are incompatible with our needs. Our mapping teams
> work to scrub these contributions for consistency and quality.
>
> What’s Included in the Daylight Map Distribution:
>
>   • A PBF planet file composed of 100% OSM data, released under the terms 
> of
> the Open Database License.
>   • Only those edits which have been validated to contain no malicious
> vandalism or unintentional errors so we can show them in our display maps
>
> This is just an initial first release, and we’re looking for feedback from
> the community to decide what would be useful to release in the future and
> how frequently. I’d be interested to hear any response you might have about
> it!
>
> -mike.
>
> 
> michal migurski- contact info and pgp key:
> sf/cahttp://mike.teczno.com/contact.html
>
>
> ___
> 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] checking before massive deletion

[Joseph Eisenberg]

Here in Indonesia there were many place nodes imported from official
sources, but the government database had very poor quality in large
parts of the country, especially my province.

At first I tried to move the nodes to the right place, and was
hesitant to delete them, but later I realized that I would waste many
hours trying to fix the damage.

I recommend deleting the nodes if you have found that they are all in
the wrong place by more than several kilometers. (Our place=village
nodes were off by 10, 20 or 50 kilometers, which isn't helpful, and
many were just administrative names)

If they are just 1 or 2 kilometers off, then it would be worth keeping
them with a fixme=* on each one for local mappers to correct the
location later.

But that doesn't sound like it is the case in this situation.

- Joseph Eisenberg

On 3/10/20, Mario Frasca  wrote:
> hello here,
>
> I wish to get some sort of support in a decision regarding data which I
> find hard to verify, and actually also hard to believe.
>
> years ago ArielRod completed this changeset:
> https://www.openstreetmap.org/changeset/17323627
>
> I have asked about the source, and got no reply.
>
> the above is not an isolated changeset, for there are at the moment 995
> place=* on ArielRod's name in the "Comarca Ngäbe Buglé", and 342 in
> Chiriquí.  these are the points added by this user, and not edited by
> others.  but there are more, where people have edited them downgrading
> place to isolated_dwelling, just in doubt instead of deletion, I suppose.
>
> the alleged source is the census for the year 2010, but the
> corresponding document, as far as I managed to search
> (https://inec.gob.pa/archivos/P3551P3551cuadro3.xls) does not contain
> coordinates.
>
> I have zoomed into quite a few of these points marked as place=hamlet,
> and in most cases I do not see anything that could justify the presence
> of a `isolated_dwelling`.  in some cases, there is something, but is it
> sheer chance?  could well be.
>
> one example for all, Node: Bulite (2416914927), marked as hamlet,
> supposedly 5 houses according to the census.
>
> https://www.openstreetmap.org/node/2416914927#map=17/8.54709/-81.76901=D
>
> around this node, at less than 1.0km, there's 18 more place=hamlet, by
> the same user.
>
> in the same area, I do see a few buildings (I haven't mapped any), but
> not near the place=* nodes.
>
> of these 19 nodes, only 8 are actually mentioned, verbatim, in the 2010
> census.  but still, whether they have been thrown at a random location,
> or placed here for any other reason, that's obscure to me.
>
> so far the situation.
>
> I would like to do some cleaning up, and am considering deleting all
> such nodes added by this user, either edited by others, or not.  I have
> commented so much in the Panama Telegram Group, where a few local
> editors are active, asking for their opinion.  none has been expressed
> so far.  I would not want to act without some support.
>
> I could also leave it as it is.  after all, why should I care?
>
> comments will be very welcome,
>
> best regards, Mario Frasca
>
>
> ___
> 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] Attribution guideline update

[Joseph Eisenberg]

Is there any update about the attribution guidelines?

At this point is there a chance that further comments and concerns
will be addressed, or is this a "done deal", where community input is
no longer going to be considered?

- Joseph Eisenberg

On 2/19/20, Simon Poole  wrote:
> The LWG has now integrated feedback from the initial airing in August
> last year, from a total of three sessions at SOTM-US and SOTM in
> Heidelberg, feedback from the OSMF board and from the wider OSM community.
>
> Barring any major late developing issues, we intend to forward this to
> the OSMF board for formal approval at the next LWG meeting on the 12th
> of March. If you have any comments please feel free to add them to the
> wikis talk page.
>
> The updated document can be found here
> https://wiki.openstreetmap.org/wiki/Draft_Attribution_Guideline
>
> Simon
>
> PS: please disregard the numbering in the document, that will not be
> present on the OSMF wiki.
>
>
>

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

Re: [OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

[Joseph Eisenberg]

Clarification:

The Openstreetmap Carto style (which is used on the "Standard" map
layer of openstreetmap.org) does not render place=ocean or place=sea
or place=continent.

The only features discussed which are currently getting rendered are
natural=strait and natural=bay*.

Currently Openstreetmap Carto and the other 3 map styles on
openstreetmap.org are raster maps, with pre-rendered tiles stored on
the servers, so it will take a fair amount of work to make the
technical changes to render server-side vector tiles and show
different languages to different users by rendering different raster
tiles when requested.

If you want to see this happen, we could use more volunteers with the
time and ability to work out the issues.

See: https://github.com/gravitystorm/openstreetmap-carto/issues/3201

- Joseph Eisenberg

*  (I personally tried to stop rendering bays and straits at low zoom
levels, since I think it is a mistake to render these without
place=sea, and to encourage mappers to create huge multipolygons to
get the rendering)

On 2/26/20, Frederik Ramm  wrote:
> Hi,
>
> On 26.02.20 13:13, Maarten Deen wrote:
>> Will it be nothing in the name tag and are we then going to complain
>> that the opencarto style falls back to name:en?
>
> Increasingly, I think the absence of a name tag wouldn't even be
> noticed. JOSM already shows the name tags in the editing user's
> language; other editors might do that too. If a fallback to name:en were
> added to OSM Carto (or more precisely, a fallback to a configurable
> language which would be configured to be English on openstreetmap.org)
> then you could probably remove the name tag from oceans with hardly
> anyone noticing a change.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> 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] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

[Joseph Eisenberg]

> it *is* worth discussing if (or why) the "name" tag on a body
of water bordered by a number of countries neither of which has English
as an official language, should contain the English name.

I agree. Unfortunately the message has been confused by the poor presentation.

It is quite reasonable to question the use of English in the `name=`
tag for the Baltic Sea.

It would be reasonable to stop using the name= tag for oceans,
continents and international seas, if we can develop a tag which would
specify which of the `name:=` tags should be treated as
the primary ones. This would make it more feasible to design a
rendering for the Baltic Sea, the Mediterranean, and other seas
surrounding by a large number of language areas.

For the oceans and continents there may not be much use in a name tag,
since these labels only make sense on a global map. A map designer or
user can pick the language in that case.

- Joseph Eisenberg

On 2/24/20, Martin Koppenhoefer  wrote:
>
>
> sent from a phone
>
>> On 24. Feb 2020, at 11:44, Frederik Ramm  wrote:
>>
>> We're not there yet though; we're kind of shouting down Tomek because
>> he's aggressively questioning the status quo, but we haven yet managed
>> to come up with a rule that would fortify the status quo.
>
>
>
> there has been mention of utility. From statistical research it would seem
> that English is the language which has most people able to understand it
> (shortly before Chinese, but with significantly more usage as a second
> language). From a practical point of view, there are good arguments to fall
> back to English. This could change in the future, but it would be a long
> way.
> Despite the global statistics, it could well be that regionally, other
> languages would be more useful or “natural” than English, even if that
> language isn’t the mother tongue of the majority of residents in the
> neighboring countries (e.g. Spanish, Arabic, Portuguese, Mandarin, Russian
> ...)
>
> Cheers Martin
>
>
> ___
> 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] Creation of "Data Items" by bot for undocumented tags

[Joseph Eisenberg]

Yuri, I did not find a way to open an issue about the bot
(https://github.com/Sophox/sophox/tree/metabot/metabot is a branch, so
any issues would appear to be about Sophox). Is there an appropriate
place to request changes, besides Talk:Date_items?

- Joseph Eisenberg

On 2/19/20, Mateusz Konieczny via talk  wrote:
>
>
>
> 18 Feb 2020, 21:57 by dieterdre...@gmail.com:
>
>>
>>
>> sent from a phone
>>
>>> Il giorno 18 feb 2020, alle ore 18:32, Joseph Eisenberg
>>>  ha scritto:
>>>
>>> Therefore, I propose that Yurikbot be changed to only add new data
>>> items for documented tags which already have a wiki page in at least
>>> one language. I do not see a benefit to creating date items for
>>> undocumented tags.
>>>
>>
>>
>>
>> I agree.
>>
> I agree, with main motivation of
> discouraging data items from
> replacing wiki pages.

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

Re: [OSM-talk] Attribution guideline update

[Joseph Eisenberg]

As Martin (@ dieterdreist) mentioned above, even 200 pixels is plenty
of space for the 15 character long "© Openstreetmap": that gives you
12 pixels per character width.

For example, our rendering of "Upper Hutchinson"... (field) in Chicago
is only 81 x 12 pixels for 16 characters at 10 point font (rendered in
Mapnik at standard resolution). See:
https://user-images.githubusercontent.com/42757252/73586817-17ca5100-44f6-11ea-8594-42ca9e8f980b.png
- just right of center.

If the small map is 200 pixels wide, the Openstreetmap copyright would
only take up 40% of the width, leaving plenty of room for another logo
or copyright notice.

Even if we ask for a 12 point font (14 pixels tall with white halo),
this would be about 100 pixels, which fits in half of the width of a
200 pixel window and less than half of a 250 pixel map.

But I would consider it ok to use  "© OSM" for a tiny watch screen or
tiny map that is less than 200 pixels wide (but more than 100 pixels).
It should only be necessary to use a tiny icon with a link to a
separate page if the screen or image is less than 100 pixels wide.

- Joseph Eisenberg

On 2/20/20, Mateusz Konieczny via talk  wrote:
>
>
>
> 19 Feb 2020, 21:05 by si...@poole.ch:
>
>>
>>
>>
>> Am 19.02.2020 um 20:17 schrieb Mateusz  Konieczny via talk:
>>
>>> 19 Feb 2020, 17:22 by >> dieterdre...@gmail.com>> :
>>>
>>>> But I stick to the comment that 500px are far too many  (=1000
>>>> actual retina pixels or 1500 px on a retina@3).
>>>>
>>> Yes, you may easily fit at least "© OSM"
>>> with link in such space.
>>>
>>
>> Just that people don't get the wrong idea, using attributing to  OSM
>> is completely out of the question, since when does Online  Soccer
>> Manager distribute geo-data?
>>
>>
> Obviously, it is only ok when you are constrained
> for space and there is actually no
> space for longer text.
>
> If you have let's say 450 pixels then you
> should use full name OpenStreetMap.

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

Re: [OSM-talk] Attribution guideline update

[Joseph Eisenberg]

If the map says "Copyright BoxMap, imagery copyright IRSE" in bold in
the right corner, but the Openstreetmap notice is hidden behind a tiny
"i" or ony shown briefly on app startup (which only happens after your
phone crashes or the app updates), then this gives the impression that
the data is also from BoxMap and IRSE. That is false attribution.

>  "we are only saying that if you follow the guidleine we believe you are 
> providing sufficient attribution as required by the licence"

Right, and this is our guideline which means "we won't sue you if you
follow these steps." It is perfectly reasonable to request things that
are the ethical and common-sensically "right way to do it" even if we
can't win a court verdict in London or New York or wherever. As the
guideline states, we are not claiming to have determined the legal
status in any particular country.

There is nothing wrong about requesting specific attribution details
which are not mentioned in the license. You certainly know that the
guidelines are much more specific than the license already, mainly in
the many exceptions to the normal attribution requirements which the
draft is allowing. We can also add more specific requirements and
trust that most database users will do their best to follow them.

> I would suggest reading https://sfconservancy.org/blog/?author=bkuhn "Toward 
> Copyleft Equality for All".

That article is unintelligible to me. Too many jargon terms. But I
will note that "Slippery slope" is a logical fallacy, whether you use
it to argue for stronger or weaker license enforcement and terms.
https://yourlogicalfallacyis.com/slippery-slope

- Joseph Eisenberg

On 2/19/20, Simon Poole  wrote:
>
> Am 19.02.2020 um 14:40 schrieb Joseph Eisenberg:
>>> IMHO attribution should always be required  1. on the map 2. in high
>>> contrast
>> Agreed.
>>
>> The main problem is that mobile devices, which are by far the most
>> common ways of accessing maps around the world, are only required to
>> provide attribution after a click or swipe, or even just on app
>> startup with a short "splash" screen:
> Providing attribution on splash screen is an obvious and widely accepted
> way of attribution completely independently of the guideline we are
> discussing here.
>>
>> I think there should be a statement in the guideline that
>> Openstreetmap attribution must not be inferior to attribution of other
>> data sources or the map designer. That is, if the app logo or aerial
>> imagery copyright is shown, then Openstreetmap must also be shown at
>> the same time. If Openstreetmap is relegated to a separate splash page
>> or linked page, the other copyright/logo features must also be on that
>> page.
>
> The licence does not stipulate any relative criteria for attribution wrt
> UI elements, other attribution or anything else on the screen. Adding
> such a requirement would break the open definitions requirement that all
> terms for use of the content be defined in the licence. Obviously there
> is a fine line there that we try not to cross with this guideline, in
> that we are only saying that if you follow the guidleine we believe you
> are providing sufficient attribution as required by the licence (note
> this not new, the problem is inherent in giving any guidance wrt any
> effect of the licence).
>
>> We should not give up on enforcing basic ethical behavior from
>> corporations. Everyone who has been to school knows that copying
>> without attribution is plagarism, and putting your logo on the front
>> makes it look like plagarism if Openstreetmap is relegated to a
>> non-visible page.
>
> Again, enforcing ethical behaviour is outside of the scope of open data
> licensing, at least in the definition that is used in our contributor
> terms (and which in practical terms is immutable).
>
> There is currently a lot of discussion on this topic in the OSS
> communities, but just to illustrate the kind of slippery slope you are
> venturing on to, I would suggest reading
> https://sfconservancy.org/blog/?author=bkuhn "Toward Copyleft Equality
> for All".
>
> Simon
>
>>
>> - Joseph M Eisenberg
>> (Hobbiest mapper from USA in Indonesia, volunteer contributor to the
>> Openstreetmap Carto map style. I have no financial or professional
>> interest or conflict.)
>>
>> On 2/19/20, Martin Koppenhoefer  wrote:
>>> Am Mi., 19. Feb. 2020 um 13:53 Uhr schrieb Frederik Ramm <
>>> frede...@remote.org>:
>>>
>>>>> Not to mention the most blatant attempts at sneaking corporate
>>>>> wishlist
>>>>> items into the guideline are al

Re: [OSM-talk] Attribution guideline update

[Joseph Eisenberg]

> IMHO attribution should always be required  1. on the map 2. in high contrast

Agreed.

The main problem is that mobile devices, which are by far the most
common ways of accessing maps around the world, are only required to
provide attribution after a click or swipe, or even just on app
startup with a short "splash" screen:

"mobile devices may have attribution after one interaction. Examples
of one interaction include “one click,” such as an icon or link that
opens a pop-up or new webpage, or a swipe, drag, pinch, etc."
"Alternatively, mobile devices may provide attribution on a splash
screen on application startup or in a pop-up that fades/collapses
automatically."
https://wiki.openstreetmap.org/wiki/Draft_Attribution_Guideline#Mobile_devices

This is the case even if the map takes up the whole, high-resolution
screen and there is plenty of room for a Maps.me or Mapbox + ESRI +
App logo in the right hand corner. I do not consider this reasonable,
or the excuse for "max 25% of displayed window": that could be up to
1400 x 800 pixels on my laptop.

I think there should be a statement in the guideline that
Openstreetmap attribution must not be inferior to attribution of other
data sources or the map designer. That is, if the app logo or aerial
imagery copyright is shown, then Openstreetmap must also be shown at
the same time. If Openstreetmap is relegated to a separate splash page
or linked page, the other copyright/logo features must also be on that
page.

We should not give up on enforcing basic ethical behavior from
corporations. Everyone who has been to school knows that copying
without attribution is plagarism, and putting your logo on the front
makes it look like plagarism if Openstreetmap is relegated to a
non-visible page.

- Joseph M Eisenberg
(Hobbiest mapper from USA in Indonesia, volunteer contributor to the
Openstreetmap Carto map style. I have no financial or professional
interest or conflict.)

On 2/19/20, Martin Koppenhoefer  wrote:
> Am Mi., 19. Feb. 2020 um 13:53 Uhr schrieb Frederik Ramm <
> frede...@remote.org>:
>
>> > Not to mention the most blatant attempts at sneaking corporate wishlist
>> > items into the guideline are all still there - like the 1 m^2 map
>> > area limit that has been conjured out of thin air
>>
>> True, this is a bit strange, it would have to be replaced by "an area of
>> up to 1,000 inhabitants" as per the "Substantial" guideline - though I
>> don't find the difference outrageous, in fact the 10.000m² will only be
>> *friendlier* towards non-attribution than the "1.000 inhabitatants" in
>> densely populated urban areas.
>
>
>
> I guess 10k sqm will be a stronger requirement (almost) everywhere, for
> example look at Manhattan, maybe not the densest place on earth, but surely
> one of the densers. With roughly 27500 inhabitants per sqkm, on the average
> 100x100m NYC patch there will only be 275 inhabitants.
>
>
>
> I stumbled upon the small maps section.
> __
> The following maps are each considered small:
>
>- The map takes up less than 25% of the displayed window, or
>- The map is of less than 500 device-independent pixels horizontally.
>
> Small maps may have attribution after one interaction. Examples of one
> interaction include “one click,” such as an icon or link that opens a
> pop-up or new webpage that displays attribution, or a mouseover, swipe,
> drag, pinch, etc.
> __
>
> Isn't the reason for not requiring attribution _on the map_ the limited
> space? Why is there a condition that makes (easily visible) attribution not
> mandatory for extremely large screens? There is a development from several
> screens to large screens, and pixel density is generally growing, so the
> "max 25% of the displayed window is a map" condition doesn't seem
> reasonable. IMHO attribution should always be required
>
> 1. on the map
> 2. in high contrast
>
> (3. in a lower corner, left or right)
>
> I am not sure what "device-independent pixels" means. Is this about points
> (i.e. physical, hardware screen pixels divided by the scale)? IMHO we
> should require actual, physical pixels, because it is them who determine
> whether the attribution string will be readable --- and the requirement
> should be tougher. We have seen many examples of easily readable,
> unobtrusive attribution on much smaller maps. For example the osm.org
> website on 467 pixels wide has room for a scale bar and this text: "©
> OpenStreetMap contributors # Make a Donation. Website and API terms" in a
> single line.
>
> The actual requirement for "© OpenStreetMap contributors" is around 163
> pixels. My suggestion would be to make this half: 250 pixels, maybe even
> less like 200 (theoretical) pixels for retina screens (i.e. 400 actual
> pixels on retina@2x and 600 actual pixels on retina@3x).
> Our goal is not to avoid attribution but to show it when it can reasonably
> be done.
>
>
>
>> In my opinion, if you train your AI black box with OSM data then
>> everything that comes out of your AI 

Re: [OSM-talk] IME no proposals needed | Re: Creation of "Data Items" by bot for undocumented tags

[Joseph Eisenberg]

> I have occasionally moved such pages into the user's name space when I
found them to (by content, if not by name) to be proposals for
something, rather than a documentation of something already established.

That is fine if the tag has not been used, and the page is written
like a proposal suggestion. But if the user just wants to tag a dozen
widgets as Tag:amenity=widget, it is fine to leave the Tag page in
place, and then add information as needed like "See Also the more
common tag landuse=widget which has a similar meaning", or "Some other
mappers have used this tag in a different way, with this differnet
meaning..." when necessary.

I personally check every new Tag: and Key: page (in English,
Indonesian or Spanish) every couple of weeks, and I suspect  Mateusz
Konieczny  and some other experienced wiki users also check the
Special:NewPages list frequently for the same reason. You can see that
many of the Tag: and Talk pages on
https://wiki.openstreetmap.org/wiki/Special:NewPages have been edited
by more than one user, even the ones that were made in the past month
or two.

This review effort is not yet happening for the Data Items, and since
there were >500 created by bot over Christmas (Dec 25-26th), I think
it's unlikely anyone has reviewed the recently created data items over
the past few months. Most are content-free (key=value is the only
property), but some probably need to be checked.

- Joseph Eisenberg

On 2/19/20, Frederik Ramm  wrote:
> Hi,
>
> On 19.02.20 07:33, Rory McCann wrote:
>> I don't know what your experience with the OSM wiki is, but I've created
>> new wiki pages for new tags, without bothering with proposal pages.
>
> I have occasionally moved such pages into the user's name space when I
> found them to (by content, if not by name) to be proposals for
> something, rather than a documentation of something already established.
> I felt that was ok since there's no rule against moving stuff into user
> name spaces ;)
>
> Anyway, I'm fine as long as we agree that data items shouldn't be
> created for tags that don't have a human-readable page, and
> human-readable pages should be created by humans not bots.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> 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] Creation of "Data Items" by bot for undocumented tags

[Joseph Eisenberg]

> How is this synchronized?
> Will every user be able to change the definition of any tag for everyone?
>Is there some kind of moderation or peer review?

Good questions. If the tag is already frequently used, the description
should be based on how the tag has been used, not merely on one user’s
opinions.

>Or is it a question whether you’re the first person or not and modifying
is not possible?

If the tag has never before been used, then it would make sense to ask the
mapper to describe the tag when they attempt to add it in JOSM or iD etc.

This suggests that an Item:Q page should be be created by the Editor
application at the time when the “description=“ is added.
Is there any technical reason that would not work?

Could a stub Wiki Tag: or Key: page be created instead or in addition?

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

Re: [OSM-talk] Creation of "Data Items" by bot for undocumented tags

[Joseph Eisenberg]

> “ we refuse to allow a wiki page about an item, but instead demand that
each key page go through a proposals process”

This is incorrect. Anyone can make a new wiki page for a tag, and it
happens several times a day on average. There are more new Tag: and Key:
pages than new proposal pages.

I did not say anything against creating wiki pages to document tags. When I
last asked about this, it was clear that most people think it is fine to
follow
“Any Tags You Like” by creating new wiki
pages for any tag you have used.

But I am unhappy with the bot creating Item:Q pages which are essential
blank: they only have the key=value and the item Q code.

What do you see as the benefit for creating such a data Item page for any
tag which has been used merely a dozen times and has not been documented
anywhere?

The claim above is that mappers should be able to add a description or
translation or in JOSM or iD directly, but couldn’t the Item:Q* page be
created at that time?

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

[OSM-talk] Creation of "Data Items" by bot for undocumented tags

[Joseph Eisenberg]

Data Items should not be created by bot for undocumented tags.

According to 
https://wiki.openstreetmap.org/wiki/Data_items#Item_Creation_Process
the Data Items (aka "Wikibase" or "Wiki Data items") are automatically
created by a bot, even before a tag is documented, if a tag has a
certain standard format and more than 10 uses in the database.

The data item is created in this case with the text "‎Created a new
Item: Auto-updating from Wiki pages" - e.g.
https://wiki.openstreetmap.org/w/index.php?title=Item:Q19947=history

This is confusing to users. For example, Item:Q19947 above,
"landuse=research" was created before there was a wiki page. Then
yesterday a user documented the tag with a page, but did not
understand why there was already a data item:

"Wikibase entry: evidence for preceding deletion? I've just created
landuse=research, but the data item
https://wiki.openstreetmap.org/w/index.php?title=Item:Q19947=history
was already existing in December '19. How was the data item then
created?"
https://wiki.openstreetmap.org/wiki/Talk:Wiki=#Wikibase_entry:_evidence_for_preceding_deletion.3F

Besided the potential confusion caused by creating these items by
bots, I think it is a bad idea to encourage wiki users to start
editing these data items without first creating an actual
human-readable wiki page to document the tag.

In theory, the "Data Items" can be useful if they properly document
how tags are used, in a way that is easier for computers to handle,
but this only works if the data is maintained and updated.

Creating a new wiki page (by human) will alert other users via
"Special:Recent" and "Special:NewPages", while the stream of items
created by bots is too much for humans to maintain, and the page names
are too obscure (Item: Q19947 is meaningless) to be scanned by humans.

Therefore, I propose that Yurikbot be changed to only add new data
items for documented tags which already have a wiki page in at least
one language. I do not see a benefit to creating date items for
undocumented tags.

Joseph Eisenberg

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

Re: [OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

[Joseph Eisenberg]

> - for continents, oceans, poles, and seas bordering any state, I will
completely remove this marker.

I'm almost certain that this translation is wrong. It doesn't make sense.

Could you check the correct translation of "por kontinentoj, oceanoj,
polusoj kaj maroj kiuj apudas al neniu lando, tute forigi tiun ĉi
etikedon."

Does this mean "... NOT bordering any country"? That's what Google
translate suggests: " for continents, oceans, poles and seas that are
next to none country, completely remove this tag."

(Still wrong but at least I can understand it... That's the problem
with relying on automated translation software... it doesn't work
well.)

- Joseph Eisenberg

On 2/18/20, Joseph Eisenberg  wrote:
> Since this issue is somewhat controversial, it would be best to create
> a proposal page to suggest the proper way to tag continents, oceans
> and seas - these tags were never formally discussed, and have some
> problems.
>
> Also, the correct way to propose automatically changing a large number
> of features is to follow the "Automated Edits code of conduct":
> https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
>
> This includes "systematic edits to the database by other means without
> consideration of each change. This policy also applies to substantial
> changes made using 'find and replace' or similar functions within
> standard editors such as JOSM" - so I believe this would be the case
> for editing all the seas and oceans.
>
> "You should normally document your proposed edit at an
> English-language wiki page named "Automated edits/username" (where
> username is the OSM user name of the account that you will be using to
> perform the edits - think about this now so that you don't have to
> rename the page later), and add it to Category:Automated edits log.
>
> Your documentation should state:
>
> Who is making the change (preferably your real name and how to contact
> you, ideally e-mail address)
> Your motivation for making the change and why it is important
> A detailed description of the algorithm you will use to decide which
> objects are changed how
> Information about any consultation that you have conducted, with links
> to mailing list/forum posts or Wiki discussion pages
> When the change was made, or how frequently it is going to be repeated
> Information on how to "opt out"
>
> Please read the rest of the information at
> https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
> prior to proceeding.
>
> (FYI, I am personally in favor of removing the English name=* tags for
> continents and oceans, and perhaps for many of the seas, but it's
> important to get consensus about a major edit like this)
>
> - Joseph Eisenberg
>
> On 2/18/20, Tomek  wrote:
>> W dniu 20-02-15 o 19:17, Steve Doerr pisze:
>>> On 15/02/2020 17:35, Tomek wrote:
>>>> - for continents, oceans, poles, and seas bordering any state, I will
>>>> completely remove this marker.
>>>
>>> Don't do that. The golden rule should be: never remove another
>>> mapper's contribution unless it's incontrovertibly wrong.
>>>
>>> Steve
>>>
>> EO
>> Mi provas provi ke la etikedo “name” por tiuj objektoj estas erara.
>>
>> Objekto 1:
>> https://commons.wikimedia.org/wiki/File:Jardin_El_Capricho_Bench_at_Plaza_de_los_Emperadores.jpg
>> Benko kun neniu skribaĵo, mapigita en OSM kiel:
>> amenity=bench
>> name=Bench
>> Ĉu estas ĝuste forigi la etikedon “name” laŭ la regulo mi “mi mapigas
>> tion, kion estas sur la tero”?
>>
>> Objekto 2:
>> https://commons.wikimedia.org/wiki/File:Turquoise_Water.jpg
>> Akvo, certege neniu skribaĵo indikanta ĝian nomon.
>> Loka nomo: neniu, ĉar neniu loĝas tie.
>> Mapigita en OSM kiel:
>> place=ocean
>> name=Pacific Ocean
>> Sed poloj nomas ĝin “Ocean Spokojny”, franclingvanoj “Océan Pacifique”,
>> do estus ĝuste aldoni la etikedojn name:pl, name:fr, ktp.
>> Ĉu estas ĝuste forigi la etikedon “name” laŭ la sama regulo?
>>
>>
>> EN (machine translation)
>> I'm trying to prove that the tag "name" for those objects is wrong.
>>
>> Object 1:
>> https://commons.wikimedia.org/wiki/File:Jardin_El_Capricho_Bench_at_Plaza_de_los_Emperadores.jpg
>> Bench with no writing, mapped to OSM as:
>> amenity = bench
>> name = Bench
>> Is it right to remove the label "name" according to the "I'm mapping
>> what's on the ground" rule?
>>
>> Object 2:
>> https://commons.wikimedia.org/wiki/File:Turquoise_Water.jpg
>> Water, certainly no writing indica

Re: [OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

[Joseph Eisenberg]

Since this issue is somewhat controversial, it would be best to create
a proposal page to suggest the proper way to tag continents, oceans
and seas - these tags were never formally discussed, and have some
problems.

Also, the correct way to propose automatically changing a large number
of features is to follow the "Automated Edits code of conduct":
https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct

This includes "systematic edits to the database by other means without
consideration of each change. This policy also applies to substantial
changes made using 'find and replace' or similar functions within
standard editors such as JOSM" - so I believe this would be the case
for editing all the seas and oceans.

"You should normally document your proposed edit at an
English-language wiki page named "Automated edits/username" (where
username is the OSM user name of the account that you will be using to
perform the edits - think about this now so that you don't have to
rename the page later), and add it to Category:Automated edits log.

Your documentation should state:

Who is making the change (preferably your real name and how to contact
you, ideally e-mail address)
Your motivation for making the change and why it is important
A detailed description of the algorithm you will use to decide which
objects are changed how
Information about any consultation that you have conducted, with links
to mailing list/forum posts or Wiki discussion pages
When the change was made, or how frequently it is going to be repeated
Information on how to "opt out"

Please read the rest of the information at
https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
prior to proceeding.

(FYI, I am personally in favor of removing the English name=* tags for
continents and oceans, and perhaps for many of the seas, but it's
important to get consensus about a major edit like this)

- Joseph Eisenberg

On 2/18/20, Tomek  wrote:
> W dniu 20-02-15 o 19:17, Steve Doerr pisze:
>> On 15/02/2020 17:35, Tomek wrote:
>>> - for continents, oceans, poles, and seas bordering any state, I will
>>> completely remove this marker.
>>
>> Don't do that. The golden rule should be: never remove another
>> mapper's contribution unless it's incontrovertibly wrong.
>>
>> Steve
>>
> EO
> Mi provas provi ke la etikedo “name” por tiuj objektoj estas erara.
>
> Objekto 1:
> https://commons.wikimedia.org/wiki/File:Jardin_El_Capricho_Bench_at_Plaza_de_los_Emperadores.jpg
> Benko kun neniu skribaĵo, mapigita en OSM kiel:
> amenity=bench
> name=Bench
> Ĉu estas ĝuste forigi la etikedon “name” laŭ la regulo mi “mi mapigas
> tion, kion estas sur la tero”?
>
> Objekto 2:
> https://commons.wikimedia.org/wiki/File:Turquoise_Water.jpg
> Akvo, certege neniu skribaĵo indikanta ĝian nomon.
> Loka nomo: neniu, ĉar neniu loĝas tie.
> Mapigita en OSM kiel:
> place=ocean
> name=Pacific Ocean
> Sed poloj nomas ĝin “Ocean Spokojny”, franclingvanoj “Océan Pacifique”,
> do estus ĝuste aldoni la etikedojn name:pl, name:fr, ktp.
> Ĉu estas ĝuste forigi la etikedon “name” laŭ la sama regulo?
>
>
> EN (machine translation)
> I'm trying to prove that the tag "name" for those objects is wrong.
>
> Object 1:
> https://commons.wikimedia.org/wiki/File:Jardin_El_Capricho_Bench_at_Plaza_de_los_Emperadores.jpg
> Bench with no writing, mapped to OSM as:
> amenity = bench
> name = Bench
> Is it right to remove the label "name" according to the "I'm mapping
> what's on the ground" rule?
>
> Object 2:
> https://commons.wikimedia.org/wiki/File:Turquoise_Water.jpg
> Water, certainly no writing indicating its name.
> Local name: nobody, because nobody lives there.
> Mapped in OSM as:
> place = ocean
> name = Pacific Ocean
> But Poles call it "Ocean Spokojny", French-speaking "Océan Pacifique",
> so it would be fair to add the tags name:pl, name:fr, etc.
> Is it OK to remove the "name" tag according to the same rule?
>
>
>
> W dniu 20-02-16 o 12:44, Florimond Berthoux pisze:
>>
>> - for continents, oceans, poles, and seas bordering any state, I will
>> completely remove this marker.
>>
>>
>> Warning, without giving my opinion, I don't know all involvements.
>> Data should not be lost!
> EO
> Neniuj datumoj perdiĝos, la angla nomo estos en la etikedo “name:en”!
> EN
> No data will be lost, the English name will be labeled "name:en"!
> FR
> Aucune donnée ne sera perdue, le nom anglais sera étiqueté "name:en"!
>

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

[Talk-us] Tagging "Junior College" or "Community College"?

[Joseph Eisenberg]

How are people tagging places known as "junior colleges" or "community
colleges?" Usually these offer 1 or 2 year associates degrees and
diplomas in specific trades or work fields, or general higher
education courses which make it possible to transfer to a 4-year
University.

Is it proper to use amenity=college? That tag was originally developed
for insitutes of "Further Education" in the UK, which are a bit
different than North American junior/community colleges. Is anyone
using amenity=university instead?

- Joseph Eisenberg

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

Re: [OSM-talk] copying numbering (ref)

[Joseph Eisenberg]

> “ they don't really use numbers for roads except internally”

If they do not post signs, and locals do not usually know the numbers, then
there should not be a ref for those provincial roads in Openstreetmap.

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

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Joseph Eisenberg]

> Re: "Similarly, type=route relations (road, bicycle, hiking, equestrian...) 
> enter OSM from ODbL-compatible government-published maps, yet remain unsigned 
> (or poorly signed) in the real world."

Please do not add this section. Most types of route relation should
only be mapped if they are actually signed. Some which are fixed-route
public services can be mapped based on actually riding the route,
which is also a real-world method of verification which does not
depend on consulting an external map or document. I do not think the
"good practice" page should mention mapping routes which are not
verifiable in the real world, which only exist on paper. While some
mappers like to add such things (like "proposed" bicycle routes or
hiking routes which only exist in guidebooks and have no signs), this
is not a good practice.

> Re: "on a government map, by legal / statutory decree, from data 
> authoritatively published on a website"

These examples are not "good practice" sources for openstreetmap.
While many mappers import data from such sources, there is no "value
added" in the case that mappers are unable to confirm if the
government or "authoritative" data is accurate or inaccurate. Since
the data in Openstreetmap can be changed at any time, and often by
mistakes caused by new mappers, the authoritative database or source
will always be better for database users to consult directly, unless
openstreetmap can improve the originally imported data by checking it
against reality.

Remember, this is the "good practice" page we are talking about
editing, not the "how things really are done" page: we want to focuse
on the "Gold Standard", best practices.

- Joseph Eisenberg

On 2/9/20, stevea  wrote:
> Done:
>
> https://wiki.osm.org/wiki/Talk:Good_practice#Supplementing_and_clarifying_the_On_The_Ground_.22rule.22
>
> Follow it there, if you like.
>
> SteveA
>
>> On Feb 8, 2020, at 12:04 PM, Yuri Astrakhan 
>> wrote:
>>
>> I am in favor of this or similar language.  I think for a more vote-like
>> discussion it might be better to use the wiki talk page (easier to add +1s
>> and short comments).
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>

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

[OSM-talk] OpenStreetMap Carto release v4.25.0

[Joseph Eisenberg]

Dear all,

Today, v4.25.0 of the OpenStreetMap Carto stylesheet (the default
stylesheet on the OSM website) has been released. Once changes are deployed
on the openstreetmap.org it will take couple of days before all tiles
show the new rendering.

Changes include:

* Remove rendering of barrier=embankment (#4010)

Embankments are now commonly tagged with man_made=embankment or
man_made=dyke

* Remove rendering of barrier=kerb (#3969)

 This feature is not similar to common barriers (fences and walls)

* Remove boundary=protected_area fill color at low zoom levels (#3887)

 Also changes protected area line and text to new @protected-area

* Remove polygon fill rendering for barrier=hedge areas (#3844)

 This makes the rendering consistent between walls and hedges as areas

* Remove operator text label for most amenity=vending_machine (#3965)

Operator= label is still rendered for vending=public_transport_tickets

* Add svg icon for parking=multi-storey + amenity=parking_entrance (#3599)

* Fix syntax of font list and enable Armenian font (#3989)

* Use text-dy for wind generators only, not for other power=generator
features (#3964)

* Use ST_PointOnSurface for bridge names (#3902)

* Use ST_PointOnSurface for text-poly-low-zoom (#3921)

* Use ST_PointOnSurface for roads-area-text-name (#3932)

* Use ST_PointOnSurface for junctions (#3933)

These PRs complete the switch to ST_PointOnSurface for labeling
all polygon features with text labels, which was began a year ago.

* Minor code clean-ups:

Remove way_pixels selection from bridge layer (#3950)
Remove name from SQL select when unused (#3947)
Combine line-barriers and area-barriers layers into one

Thanks to all the contributors for this release, including @Sjord
(Sjoerd Langkemper), a new contributor.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/$v4.24.1...v4.25.0

As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues and new contributions

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

Re: [OSM-talk] Tag:man_made=embankment

[Joseph Eisenberg]

It would be helpful to link the the particular objects in the database
or places which you are thinking about.

> it is a land fill and there is something on the top

If it is a landfill with a high, flat top and steep slopes on each
side, it would be appropriate to use a closed way around the edge of
the flat top, and tag it with man_made=embankment. This means that the
arrows on the line should be going in the counter-clockwise direction,
so that the low ground is on the right side of the way.

>a big hole in the case of an retention dry pond

In this case you can just use landuse=basin + basin=retention, but you
can also also draw the top of the slopes on each side. If the
retention basin is completely circled by steep slopes, you could draw
a line all the way around, but this time in the CLOCKWISE direction,
since the lower ground is on the right-hand side.

I hope this makes sense now.

- Joseph Eisenberg

On 1/16/20, 80hnhtv4agou--- via talk  wrote:
>
> maybe i asked it wrong, there is no way per say, it is a land fill and there
> is something on the top, but to the
>
> tracers looking at bing it looks flat but it is a big mountain, on the one
> hand or a big hole in the case
>
> of an reintion dry pond
>
> in the case of a road, on the top of a mound or below street leave.
>
> that is to show that these things are not on the ground leave.
>
> From: Pierre Béland via talk
> Sent: Wednesday, January 15, 2020 1:28 PM
> To: talk@openstreetmap.org ;  Paul Johnson ;  Yves
> Subject: Re: [OSM-talk] Tag:man_made=embankment
>
> I think that there is a miss-conception here. If you want to talk about the
> wall the retains the earth, this is the dyke. The embankment is more then a
> wall and is at least as large as the road and made of resistant material.
> The wiki pages  https://wiki.openstreetmap.org/wiki/Key:embankment and
> https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dembankment do not accept
> usage of polygones with these tags.
> see description of embankments in
> https://www.sciencedirect.com/topics/engineering/highway-embankment
>
>
> Pierre
>
>
> Le mercredi 15 janvier 2020 13 h 56 min 45 s UTC−5, Yves <
> yve...@mailbox.org > a écrit :
>
>
> You should have read "right side of way" : it's the side on your right when
> you follow the way in its direction.
> Yves
>
> Le 15 janvier 2020 17:59:42 GMT+01:00, Paul Johnson < ba...@ursamundi.org >
> a écrit :
>>
>>
>>On Wed, Jan 15, 2020 at 10:28 AM 80hnhtv4agou--- via talk <
>> talk@openstreetmap.org > wrote:
>>>What does this mean ?
>>>
>>>“ should be tagged on a way drawn with the   lower side on right side   of
>>> way direction”
>>
>>The downhill side of the embankment is to the right of the way.
> ___
> 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 mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Deleting template parameters copied to data items

[Joseph Eisenberg]

We are aware how the wiki data items were created and populated by bot.

> This suggestion would not change anything other than grabbing information 
> from the item. This would also mean that if someone wants to add information 
> it would best be done on the item.

These two sentences are contradictory. By bringing information only
from the wiki data items, it would be necessary to edit and maintain
those, as well as the wiki page text, on each Tag: and Key: and
feature page.

This is increasing the maintenance overhead, steeping the learning
curve for new users, and making it more difficult to find out how the
system works.

> Wikidata is BTW very rapidly becoming the most popular wiki with an 
> increasing number of editors.

Facebook may also be growing rapidly, but this does not make it a good
company. And Openstreetmap is not at all like Wikidata: we are a
primary source, created from observation of real-world data.

You have not provided any use case for the wiki data items.

I will give you one: with the wiki data items it is possible to add
only a description field for a certain language, and then in theory if
taginfo were updated to use this, it would then be possible to make a
new list of Map Features for a langauge without having to make a new
wiki page, specific to that langage, for each Feature.

However, as someone who has been editing the Indonesian language page,
I think it is very important to have complete wiki pages for all the
major features: a one-line description is not enough to explain how a
tag is used.

And it's much easier to translate a new page all in one place, in the
text editor, than having to edit things in the wiki data item and also
then write out the page.

-Joseph Eisenberg

On 1/15/20, pang...@riseup.net  wrote:
> Hi Christoph
> Could you please comment on the wiki instead?
> I never saw you on the wiki, so I'm not surprised to see that your opinion
> is not voiced there at all to my knowledge.
>
> To the casual scroll-by reader who is not familiar with how the wiki works:
> as of now there is a bot who keeps the data items up to date from wiki
> taginfo boxes. This suggestion would not change anything other than grabbing
> information from the item. This would also mean that if someone wants to add
> information it would best be done on the item.
> The items are linked on the left from all wikipages and are very similar to
> how wikidata works.
>
> Wikidata is BTW very rapidly becoming the most popular wiki with an
> increasing number of editors. It is not that huge an effort to learn how
> statements work and I'm sure we could create a good introduction if anyone
> needs it. My suggestion is to look at the video introduction and perhaps a
> video about the wikidata interface and then just go ahead and be bold on our
> items 
>
> If you have questions about how data items work see
> https://wiki.openstreetmap.org/wiki/Data_items
>
> Cheers
>
> On January 15, 2020 2:03:29 PM GMT+01:00, Christoph Hormann 
> wrote:
>>On Wednesday 15 January 2020, Mateusz Konieczny wrote:
>>> PangoSE started "Transition to use data items when this can be done
>>> without loosing information" discussion at
>>> https://wiki.openstreetmap.org/wiki/Talk:Wiki#Transition_to_use_data_
>>>items_when_this_can_be_done_without_loosing_information
>>> <https://slack-redir.net/link?url=https%3A%2F%2Fwiki.openstreetmap.or
>>>g%2Fwiki%2FTalk%3AWiki%23Transition_to_use_data_items_when_this_can_be
>>>_done_without_loosing_information=3>
>>>
>>> It is about whatever it is correct to delete data from the OSM Wiki
>>> page after it was copied to data items.
>>>
>>> Anyone with opinion on that topic is welcomed to comment in this
>>> discussion on the OSM Wiki.
>>
>>This is a move that has been a long time coming as part of a piecemeal
>>effort by some to establish a technocratic rule on the OSM wiki by
>>moving central content out of the control of the mappers into the
>>domain of data items with higher hurdles of participation due to poor
>>ergonomics (the whole concept of requiring human editors to deal with
>>numerical IDs for features that already have a unique identifier in OSM
>>
>>by design never ceases to amaze me) and with an established ability of
>>the technocrats to control the crowd sourced editing work with bots.
>>
>>Quite obviously that it is not a good idea.  But it does not matter
>>much
>>because the community has plenty of options to work around this should
>>it indeed be implemented against the interests of the mapper community.
>>
>>I would for example if something in the info box is wrong and this is
>>not part of the wiki page of a tag

Re: [OSM-talk] Too subjective & problematic Re: no-go-areas

[Joseph Eisenberg]

In the USA a postal code is not actually an area, but a set of
addresses. Often they are all in one area, but sometimes the area is
not clearly defined. This is partially why postal codes are usually
just added to the POI directly in the USA. Trying to make a sensible
set of areas or boundaries will not work for all USPS postal codes.

Joseph Eisenberg

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

Re: [OSM-talk] international project communication (was: names of international objects)

[Joseph Eisenberg]

> 3. (b) should be rendered on openstreetmap.org with its English name (both 
> are independent of each other).

The place to discuss that particular question is:

http://github.com/gravitystorm/openstreetmap-carto/issues

In particular:

Request to render Oceans/Seas:
https://github.com/gravitystorm/openstreetmap-carto/issues/2278

Related to Bays/Straits:
https://github.com/gravitystorm/openstreetmap-carto/issues/3634

Joseph Eisenberg

On 1/13/20, Frederik Ramm  wrote:
> Hi,
>
> so we've heard a broad range of opinions here, and no doubt many things
> have been said that will with pleasure be pulled out of context in years
> to come, proving how unwelcoming OSM is to anyone who doesn't submit to
> the diktat of English.
>
> I would like to stress:
>
> 1. You do not need English for normal everyday participation in
> OpenStreetMap. Our website and editors are translated into dozens of
> languages, and regionally you can do your mapping in your language
> without having to discuss with anyone from another country or continent.
> In fact, if you are local to a place, your local knowledge will trump
> that of overseas English-speakers in 10 of 10 cases.
>
> 2. By nature, once things require agreement between different groups
> speaking different languages, a pragmatic solution needs to be found
> that allows people from these groups to communicate. By default, this
> will be English; though if the involved parties agree to use a different
> language that's just fine.
>
> 3. It is a valid question whether something like a body of water
> bordered by 5 countries, none of which uses English, (a) should have a
> name tag with an English name in it, and (b) should be rendered on
> openstreetmap.org with its English name (both are independent of each
> other).
>
> 4. This is not a matter that should be driven by zealotry; we need to be
> pragmatic here. If a decision is made to change something, it might make
> sense to decide on "phasing something out" and "phasing something else
> in", or decide to make a change at a later date, so that map style
> makers etc. could prepare adequately.
>
> 5. The usual language on this list is English. If you cannot use English
> but want to make an important point, post in your language and we'll
> make an effort to understand, or those who share your language will
> translate. If you *can* use English but don't use it because you want to
> make the point that the reliance on English is giving an unfair
> advantage to those who can use English - your point is taken, but see #1...
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> 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] Fwd: [Tagging] Tagging the local language

[Joseph Eisenberg]

> a change in the urban structure (urban confuguration, architectural style, 
> living standards, socially / ownerstructure, etc.). can mark a border very 
> strongly in some instances

Right, that's why we can map landuse=residential, landuse=industrial,
landuse=commercial and landuse=retail as areas with clear boundaries.

- Joseph Eisenberg

On 1/12/20, Martin Koppenhoefer  wrote:
> Am Sa., 11. Jan. 2020 um 01:30 Uhr schrieb Joseph Eisenberg <
> joseph.eisenb...@gmail.com>:
>
>> On Sat, Jan 11, 2020 at 2:49 AM Mateusz Konieczny
>> 
>> wrote:
>>
>>> or to use tricks like the “place=neighbourhood” one (which is based on
>>> POIs rather than polygons)?
>>>
>>> It is certainly wrong to do this.
>>>
>>
>> I think the “trick” here is referring to the stand at practice of mapping
>> all place= features as nodes, including neighborhoods, because their
>> boundaries are usually fuzzy (and precise boundaries can be mapped with
>> boundary=administrative or another boundary= tag).
>>
>
>
>
> mostly I agree, although it should be mentioned that neighbourhood (or
> other place boundaries like quarter and suburb) may be very clear although
> they aren't officially declared: when they are hard "natural" borders like
> railroads, rivers, motorways, etc. Also a change in the urban structure
> (urban confuguration, architectural style, living standards, socially /
> ownerstructure, etc.). can mark a border very strongly in some instances,
> without it having to be an administrative boundary.
>
> Cheers
> Martin
>

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

[OSM-talk] Fwd: [Tagging] Tagging the local language

[Joseph Eisenberg]

On Sat, Jan 11, 2020 at 2:49 AM Mateusz Konieczny 
wrote:

> or to use tricks like the “place=neighbourhood” one (which is based on
> POIs rather than polygons)?
>
> It is certainly wrong to do this.
>

I think the “trick” here is referring to the stand at practice of mapping
all place= features as nodes, including neighborhoods, because their
boundaries are usually fuzzy (and precise boundaries can be mapped with
boundary=administrative or another boundary= tag).

Oceans are better mapped as nodes because the cause no harm this way, and
database users can even use the node to find out the names in various
languages, and use them to put a label in a hand-selected place.

Mapping oceans (And seas) as multipolygons using the coastline would be
much worse, because the huge relations would be hard to maintain, the
borders between oceans would arbitrary and not verifiable, and editing the
coastline anywhere would be very likely to cause an editing conflict.

(These trains are also why it is a bad idea to map large bays, seas and
straits as areas)

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

Re: [OSM-talk] [Tagging] Tagging the local language

[Joseph Eisenberg]

The main problem with tagging continents is that there is no agreement
on the number or definition.

While most English-speakers identify 7 political continents, many
people in Latin American call "America" one continent. Eurasia is
often also treated as one continent, leading to 5 continents (with
Africa, Australia and Antarctica).

Geographically, Africa is connected to Asia, with only the artificial
Suez Canal as a barrier, so 4 continents is also logical.

Naming and dividing the oceans leads to similar issues.

- Joseph Eisenberg

On 1/8/20, Mario Frasca  wrote:
> On 07/01/2020 06:53, Martin Constantino–Bodin wrote:
>> Maybe we can sometimes factorise? Like “América del Sur / do Sul” for
>> South America
>
> fortunate case: it's América in both languages (Catalan has Amèrica).
>
> you can possibly even use América Meridional and cover both in one shot.
>
>
> ___
> 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] Railway improvements; stations vs. halts

[Joseph Eisenberg]

According to the wiki page, railway=halt is mainly used for "A small
station, may not have a platform, trains may only stop on request."
The presence of points/switches is only significant in Germany.

I would recommend reverting to railway=station for any which have
platforms and are regularly scheduled places for the train to stop.

-Joseph Eisenberg

On 1/8/20, Clay Smalley  wrote:
> Hi all,
>
> Over the last few months, I've been doing some systematic improvements to
> the passenger railway network across North America. Much of this has been
> filling out public_transport=stop_area relations for every railway station,
> including stop positions and platforms, as well as verifying the geometry
> of the underlying railways and classifying them (usage=*, service=*). My
> goal here is to prepare the map such that route relations can be more
> meaningful and accurately describe which track each train uses.
>
> In the course of doing this, I got a tap on the shoulder [1] and found out
> I was using a definition of railway=halt that may not match up with what
> people were expecting. As far as I know now, railway=station was originally
> intended for stations where trains are always scheduled to stop, and
> railway=halt for flag stops (aka request stops). In the German OSM
> community, there was a decision made for railway=halt to be used on
> stations that are missing switches, which means trains cannot switch
> tracks, terminate or reverse direction there—a distinction more relevant to
> railway operations and scheduling. Naturally, there are quite a lot more of
> these than flag stops.
>
> I'm in a predicament here. So far, I've mapped all Amtrak stations and
> various commuter rail stations across the Northeast according to the
> no-switches definition of halt. I'm happy to revert these back to stations
> (wherever they aren't flag stops), though I'd like to hear others' thoughts
> before going through with that.
>
> -Clay
>
> [1] https://www.openstreetmap.org/changeset/77959450
>

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

Re: [OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

[Joseph Eisenberg]

> ... the osm.org styles base themselves on the “name” tag to determine the 
> default style? Or is this that the way the styles are currently defined do 
> not enable the definition of heuristics to pick the best “name:*” tag if the 
> “name” tag itself is absent? I really don’t know the styling part of OSM 
> renderrers, but it seems to be crucial in this discussion: can you elaborate 
> on this?

The "Standard" map layer on openstreetmap.org is in the
Openstreetmap-carto style, the details of which are open source at
https://github.com/gravitystorm/openstreetmap-carto/ - most features,
including bays, straits, lakes and other large natural features, have
a text lable displaed based on the "name=*" tag. This is also common
for some other styles which intend to serve the whole globe, since the
"name=" tag should include the common local name, in whatever language
or langauges the local mappers have chosen as the local standard.

In theory we could produce these name labels from tags like
"name:de=*" in Germany and "name:de=" + "name:fr=*" + "name:nl=*" in
the various parts of Belgium, but it's quite difficult to decide which
tag to use in each region.

There is currently no agreed-upon way to determine the "default"
language of a place on land. I attempted a proposal for this a year
ago, but it was not accepted (See issues at
https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format).
Before that, two similar proposals were also rejected, so currently
there is no information in our database about what name:
tags are used locally.

As far as I know there is no technically simple way to solve this
problem without picking a default language for a global map. The
current solution, which lets local mappers manually pick the "name="
for each feature, is not perfect, but it is better than guessing which
language to render for each region. While I am still in favor of a
solution that adds some sort of "default language and script" tag for
each region, it does not seem that there is enough support for that
idea to happen, so for now we need to have name=* tags for things that
are going to be rendered on global maps.

(Note that Openstreetmap-carto does not render the names of oceans,
continents and seas, but does render the names of some large bays and
straits and islands which are relevant to this discussion)

Joseph Eisenberg
(One of the maintainers of Openstreetmap-carto, mapper in Indonesia)

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

Re: [OSM-talk] SotM 2020: Scholarship review team

[Joseph Eisenberg]

Deadline is 3 days from now? If the goal is to to include a wider variety
of people from many countries, a longer deadline and messages in many
languages would be a good idea.

-Joseph Eisenberg

On Sat, Jan 4, 2020 at 7:40 PM Christine Karch 
wrote:

> Hi all,
>
> SotM WG is looking for help and for support by the community!
>
> SotM 2020 will provide a scholarship program - as we did all the years
> before. In past year for SotM 2019 the review team was mainly formed by
> the scholars of SotM 2018 and of volunteers of the local team and the
> SotM working group. We want to change this (step by step) and be more
> open to a wider community. So we ask for your help:
>
>
> https://framaforms.org/join-the-state-of-the-map-2020-scholarships-review-team-1577509125
>
> Deadline is January 7, 2020.
>
> Please spread this to all your local mailinglists and OSM friends. I
> would appreciate a larger involvement!
>
> Kind regards,
>
> Christine
>
> ___
> 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] [Osmf-talk] Attribution guideline status update

[Joseph Eisenberg]

Re: Mapbox's response:

"There are also some customers who have white-labeled in which they
don't have to provide some attributions."

What does it mean for a customer to have [been] white-labeled? Is this
like a white-list of customers who have paid extra so that they don't
have to attribute Mapbox, perhaps? Or am I misunderstanding this
phrase?

However, Openstreetmap does not have any exception for certain
customers to skip attribution because they paid a certain amount to
Mapbox or even to the OSMF.

Perhaps if many of Mapbox's customers are really unwilling to add
attribution, we could change the license to allow database users to
pay for the privelege of not providing appropriate attribution. But
right now this is not allowed by the current license.

Joseph Eisenberg

Disclosure: I have no personal financial interest in Openstreetmap,
though I do spend lots of time and some real money on it (internet
service fees, new laptop, etc), and I sometimes try to get
humanitarian organisations and businesses here in Indonesia to start
using Openstreetmap data, with appropriate attribution.

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

Re: [Talk-us] Alt_names on counties

[Joseph Eisenberg]

Thanks, Tod.

BTW, I believe the "official_name" for all California counties is now
in the format "County of Los Angeles", right? This shouldn't be used
for the "name=" since almost everyone still puts the County last (e.g.
"Los Angeles County") in common usage, but official documents will use
the other way with "of" in the middle.

Joseph Eisenberg

On 12/28/19, Tod Fitch  wrote:
> Based on this discussion and my own checking to see what search engines are
> doing with the data, I think it would be okay to move the alt_name tag value
> to be a short_name value for the counties in California and Arizona where
> the current alt_name tag is the same string as the name but without a “
> County” suffix. For example:
>
> alt_name=“Los Angeles”
> name=“Los Angeles County”
>
> Changed to
>
> name=“Los Angeles County”
> short_name=“Los Angeles”
>
> From my side this is now just a desire to be logical and consistent (not
> always a trait seen in OSM tagging). My initial annoyance has been dealt
> with on my topo map rendering by creating a Postgresql function that, among
> other things, will ignore alt_name values if they fit the above criteria. As
> noted by Joseph Eisenberg, the alt_name/short_name value could probably be
> dropped in these cases but I suspect that will get more push back than
> changing the tag.
>
> — Tod
>
>> On Dec 27, 2019, at 7:21 PM, Joseph Eisenberg 
>> wrote:
>>
>> It's not necessary to add an alternative like "Josephine" if the name=
>> is already "Josephine County" because geocoding and search application
>> already know to search for part of a name.
>>
>> For example this search already finds the "Josephine County"
>> administrative boundary as the first result:
>> https://www.openstreetmap.org/search?query=Josephine - and there is no
>> short alt_name or short_name.
>>
>> So I think there is no reason to have this information duplicated if
>> we are just worried about search.
>>
>> -Joseph Eisenberg
>>
>> On 12/27/19, stevea  wrote:
>>> I truly love the level of detail we get "coming out of the woodwork" so
>>> that
>>> we may have excellent real-life examples to share with one another (and
>>> +1
>>> to one another, too!)
>>>
>>> To be brief about it (rare for me, I endeavor to get better):  good
>>> examples, discussion / dialog and sharing our real-world experiences and
>>> knowledge is only going to help things.  If somebody reading now has a
>>> more-concrete understanding of differences between old-, alt-,
>>> official-,
>>> and so on, hooray.  If such sharper focus finds its way into a
>>> more-enlightened sentence or paragraph in a wiki, great.
>>>
>>> Chip, chip, chipping away at it (are all of us),
>>> 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
>
>

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

Re: [Talk-us] Alt_names on counties

[Joseph Eisenberg]

It's fine to use short_name= if that's a commonly-used shorter name
for a feature, which might be used by a renderer when they want a more
concise name for rendering, for example, and which is still a name
that is in use locally.

I'm just mentioning that it's not necessary to add this to help search
applications only.

- Joseph Eisenberg

On 12/28/19, stevea  wrote:
> Right:  I've wondered if short_name would be appropriate in this case.  Our
> wiki says short_name would work, Joseph says "not," though I suppose it is
> ultimately up to the search machinery and what it does.  If, indeed, as
> Joseph says, it already does this (or "they" already do this), the need for
> our documented short_name value simply goes away.
>
> SteveA
>
>> On Dec 27, 2019, at 7:21 PM, Joseph Eisenberg 
>> wrote:
>>
>> It's not necessary to add an alternative like "Josephine" if the name=
>> is already "Josephine County" because geocoding and search application
>> already know to search for part of a name.
>>
>> For example this search already finds the "Josephine County"
>> administrative boundary as the first result:
>> https://www.openstreetmap.org/search?query=Josephine - and there is no
>> short alt_name or short_name.
>>
>> So I think there is no reason to have this information duplicated if
>> we are just worried about search.
>>
>> -Joseph Eisenberg
>
>

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

Re: [Talk-us] Alt_names on counties

[Joseph Eisenberg]

It's not necessary to add an alternative like "Josephine" if the name=
is already "Josephine County" because geocoding and search application
already know to search for part of a name.

For example this search already finds the "Josephine County"
administrative boundary as the first result:
https://www.openstreetmap.org/search?query=Josephine - and there is no
short alt_name or short_name.

So I think there is no reason to have this information duplicated if
we are just worried about search.

-Joseph Eisenberg

On 12/27/19, stevea  wrote:
> I truly love the level of detail we get "coming out of the woodwork" so that
> we may have excellent real-life examples to share with one another (and +1
> to one another, too!)
>
> To be brief about it (rare for me, I endeavor to get better):  good
> examples, discussion / dialog and sharing our real-world experiences and
> knowledge is only going to help things.  If somebody reading now has a
> more-concrete understanding of differences between old-, alt-, official-,
> and so on, hooray.  If such sharper focus finds its way into a
> more-enlightened sentence or paragraph in a wiki, great.
>
> Chip, chip, chipping away at it (are all of us),
> 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-us] Alt_names on counties

[Joseph Eisenberg]

>  new freeway was just renamed for a congress person

In this case “official_name=“ with the whole congresspersons name would be
good, keeping the commonly-used name in “name=“.

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

Re: [Talk-us] Wilderness areas separate from forest?

[Joseph Eisenberg]

I agree that the current OpenStreetMap data is wrong.

For example, I grew up in the Klamath National Forest, and that area should
include the Marble Mountain wilderness, it’s shouldn’t be a hole in the
National Forest.

-Joseph

On Thu, Dec 26, 2019 at 10:40 AM Tod Fitch  wrote:

> If I am looking at the map data correctly, it seem that at least some
> designated wilderness areas are excluded from the forest that they are in.
> For example the Chumash Wilderness [1] seems to have its border as an outer
> on the Los Padres National Forest [2].
>
> This does not seem correct to me. In this specific case the wilderness is
> administered as part of the Mt. Pinos Ranger District of the Los Padres
> National Forest. I believe the same situation exists with the San Mateo
> Wilderness in the Cleveland National Forest.
>
> What is our tagging policy on this? Should the wilderness be shown as part
> of the forest that contains it? (I realize there may be wilderness areas
> that cover multiple forests but the usual case is that a wilderness area is
> a subset of a forest both geographically and administratively.
>
> Comments?
>
> Thanks
> Tod
>
>
> [1]
> https://www.openstreetmap.org/relation/2779216#map=12/34.7913/-119.1759
> [2]
> https://www.openstreetmap.org/relation/2784140#map=11/34.7975/-119.2302
> ___
> 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] [Tagging] Trunk VS primary,

[Joseph Eisenberg]

Thank you for the correction. So highway=trunk in German is similar to
expressway=yes in the USA?

Joseph

On Sun, Dec 22, 2019 at 6:49 AM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 21. Dec 2019, at 01:10, Joseph Eisenberg 
> wrote:
> >
> > Unfortunately, the road classification system in parts of Continental
> > Europe was different, so mappers in some major countries, including
> > Germany and France, chose to use highway=trunk as synonym for
> > "motorroad" (somewhat similar to a U.S.A. "expressway"), with other
> > major roads tagged as highway=primary.
>
>
> actually not, the motorroad tag was introduced by the Germans (AFAIK) to
> express a typical access situation on many trunks but also some primaries
> (motorway like access), so that trunk (motorway like physical construction)
> and access could be tagged orthogonally. There are also some trunks that
> permit slower traffic in Germany.
>
> Cheers Martin
>
>
> ___
> Tagging mailing list
> tagg...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Tagging] Trunk VS primary,

[Joseph Eisenberg]

> Being able to speak each country's highway lingua franca would make it a lot 
> easier for OSM to become the Rosetta Stone of maps simply from ease of 
> classification.

That would mean using "jalan=provinsi" instead of "highway=primary" in
Indonesia, so any global map service (like opencyclemap.org) would
need to interpret all these tags from different languages. If you
limit this to just official languages there would be several hundred
to translate, but there are over 1500 languages with a written
language currently: I don't see why we would limit things to just
official languages.

The main feature tags are in British English and they should be
translated to the appropriate local context by local mappers in each
area, rather than creating new feature tags for every country and
language, so that global maps and routing applications can continue to
work.

It's also helpful that mappers in Germany and Japan can help map my
area here in Indonesia, adding rivers, lakes and roads based on aerial
imagery. They would have trouble if they needed to learn the hundreds
of local languages in each part of Indonesia to tag things properly.

-Joseph Eisenberg

On 12/21/19, Paul Johnson  wrote:
> On Fri, Dec 20, 2019 at 1:07 AM Mateusz Konieczny 
> wrote:
>
>>
>> 20 Dec 2019, 01:25 by ba...@ursamundi.org:
>>
>> So, for example, in the US, instead of motorway, trunk, primary,
>> secondary, tertiary, perhaps something more like freeway, expressway,
>> major/minor_principal (just having this would fix a *lot* of problems
>> with
>> Texas and Missouri and their extensive secondary systems),
>> major/minor_collector...the US just has a way more complex view of how
>> highways work.
>>
>> Or at least some more serious consideration given to the proposal at
>> https://wiki.openstreetmap.org/wiki/User:UltimateRiff/HFCS (but perhaps
>> with "other principal arterials" as primary and a new
>> "highway=quartinary".
>>
>> Fitting thing like road classification
>> into UK system is irritating at times.
>>
>> But idea of each country with separate tags
>> for roads is simply a bad idea.
>>
>
> Could you expand on this?  Being able to speak each country's highway
> lingua franca would make it a lot easier for OSM to become the Rosetta
> Stone of maps simply from ease of classification.
>
>
>> This info is probably worth recording,
>> but legal status should go into a separate tag.
>>
>
> Legal status of roads in the US isn't quite as clearcut as it is in the UK,
> where the highway=* tag is literally equal to that country's legal
> classification, plus private roads with significant public passage and/or
> reach.  Off the top of my head we have 1 country, 2 states, 34 tribes, 77
> counties and 597 towns, plus MacQuarie Group Australia running the
> turnpikes and the Boy Scouts of America, Phillips 66, ConocoPhillips, or
> some combination of the three, and potentially scores more private
> entities, operating extensive networks of publicly accessible roads and
> highways in Oklahoma.  And I generally consider myself lucky I have it
> *this* straightforward in the US.
>
> Texas likely has similar situations but throw in the fact that they have 7
> different state highway systems before you get into at least 3 more
> (regional? state? private? unclear...) competing turnpike networks,
> sometimes running side by side on the same right of way (consider TX 121
> with the George Bush Turnpike operated by the North Texas Transportation
> Agency running down the median).
>
> Simply starting with the HFCS and expanding from that (particularly on the
> freeway/expressway distinction, and having more levels between secondary
> and unclassified) would be a fantastic boon to dealing with this mess in a
> more concise fashion as it changes highway=* tagging from almost entirely
> subjective to subjective but within a limited range.  Establish wiki pages
> describing how each region works and let the consumers sort it out from
> there.
>
> At an absolute minimum, we really need to establish values lower than
> tertiary yet above unclassified, and we definitely do need to make the
> freeway/expressway distinction.
>

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

Re: [OSM-talk] French OpenData improvements for distribution power networks

[Joseph Eisenberg]

I imagine you are following the import guidelines?

https://wiki.openstreetmap.org/wiki/Import/Guidelines

https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct

- Joseph Eisenberg

On 12/21/19, François Lacombe  wrote:
> Hi all
>
> I'd like to let you know about a recent and good opendata improvement in
> France regarding power networks we use to map in OSM.
> Two biggest distribution grid operators in metropolitan France, Enedis and
> Geredis, had released under Open License both overhead and underground
> network maps
>
> You may browse them here
> https://www.enedis.fr/cartographie-des-reseaux-denedis
> http://www.geredis.fr/open-data
>
> I've been involved in this seek of open data for years and found key
> insiders that understood the benefits of opening their datasets. Until now,
> community had pushed approx 800k poles and dozen of thousand km of overhead
> lines to convince operators it makes sense to check GIS against ground data
> and make it freely available.
> As a result, 800k distribution substations are now processed by osmose to
> enable anyone to integrate them directly on appropriate buildings
>
> It's not the first time such efforts are made. Power substations imports
> has been seen in Poland recently and maybe in other countries which is good
> news.
>
> This complete the already available overhead/underground French
> transmission grid map released by RTE in early 2017
> https://opendata.reseaux-energies.fr/explore/dataset/lignes-souterraines-rte/map/?disjunctive.etat=15,43.31032,5.38377=f91575
>
> Finally, there is still approximately 100 DSO companies remaining to
> convince to join this effort. They cover less than 5% of metropolitan land
> (for ~200k subscribers) to reach 100% of existing networks.
>
> All the best
>
> François
>

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

Re: [Talk-us] [Tagging] Trunk VS primary,

[Joseph Eisenberg]

Above it was said that the highway=trunk vs highway=primary
distinction is mostly for routing applications. But allowing a proper
rendering is also a main goal of the road tagging system.

While it's true that road class is useful for routing when there are
two alterate routes, a main reason to tag highways with a certain
class is to be able to render maps properly at different zoom levels.

When you are making a high-scale, low-zoom-level map of a large area
(say, the whole State of Alaska, all of England, or all of Australia),
you will want to only render highway=motorway + highway=trunk, because
showing all highway=primary would lead to rendering many smaller roads
which are not reasonable to show at that scale in most places.

In England, where these tags were developed, the distinction between
highway=trunk and highway=primary is subtle: both are "A" roads in the
official classification system, but highway=trunk has a special
sub-classification which says they are more important than other "A"
roads (tagged as primary): "UK OSM users follow the practice that all
green-signed A routes (ie primary routes) are tagged highway=trunk,
while black-and-white-signed A-roads (ie non-primary routes) are
tagged highway=primary".

Thus in the USA it's reasonable to use highway=primary for most State
and some US highways, while the most significant ones which connect
cities and large towns would be tagged highway=trunk.

Look at England at z7 on the Openstreetmap-carto style (the highest
level where highway=primary is not shown):
https://www.openstreetmap.org/#map=8/52.017/-0.261

The highway=trunk roads shown here are the main routes between cities
and towns. Zooming in to z8 shows a dense network of highway=primary
roads connecting smaller towns and large villages to towns and cities,
which would not be reasonable to show at z7

Unfortunately, the road classification system in parts of Continental
Europe was different, so mappers in some major countries, including
Germany and France, chose to use highway=trunk as synonym for
"motorroad" (somewhat similar to a U.S.A. "expressway"), with other
major roads tagged as highway=primary. If you look around the
Openstreetmap-carto rendering of Europ at z7, you will see many gaps
in the rendered road network in these countries and surrounding areas
that use the same system.

Compare Spain and Romania, which instead use highway=trunk for all major non-
motorway roads between cities: here the country-wide road network is
clearly visible with showing just highway=trunk and highway=motorway
at z6 and z7.

In the USA, it's fine to limit highway=trunk to expressways in eastern
States where all the important US highways are expressways and these
form a dense network connecting all cities and towns. But in
sparsely-populated Western states even some of the Interstate highways
are not fully motorways, and almost all US highways are just 2 lanes
(one each way) in the area between the Cascades and the Rocky
Mountains, even those that are the main cross-State routes. If we
don't tag these highways as highway=trunk it isn't possible to render
this area in a reasonable way while using the same rendering rules for
the whole USA.

Major US and State highways between cities, like AK-2 and CA-199,
CA-299, US 97 (main route in Eastern Oregon) and US 101 should be
tagged as more significant than a tiny State road in Delaware which
only connects small towns and villages.

I would suggest looking at the Indonesian road tagging guidelines
(which I was not involved in developing, but I use in mapping
locally): they show very different road quality between the developed
areas and the remote parts of the country:
https://wiki.openstreetmap.org/wiki/Indonesian_Tagging_Guidelines#Examples_of_road_class_in_several_provinces_in_Indonesia.
Most trunk roads are only 1 lane each way, but they are still the
main, National road connecting the large cities on each island. This
should be expected in other large countries like the USA, Australia
and Canada.

For tagging the status of a road as a "motorroad" or "expressway" I
would recommend using the tags motorroad=yes and expressway=yes,
rather than tagging all expressways and motorroads as highway=trunk no
matter their classification or significance in the road network. And
adding maxspeed=, surface=, lanes= and access=  will allow routing
applications and specialized renderers to treat these roads properly.

Joseph Eisenberg

On 12/21/19, Graeme Fitzpatrick  wrote:
> On Sat, 21 Dec 2019 at 08:53, Paul Allen  wrote:
>
>> On Fri, 20 Dec 2019 at 22:05, Graeme Fitzpatrick 
>> wrote:
>>
>>>
>>> But would they still count as either =trunk or =primary?
>>>
>>> While they're of high local importance, they're definitely not
>>> high-performance & they don't link major population centres either?
>>>
>>

Re: [Talk-us] Alaska Highway AK-2 tagging

[Joseph Eisenberg]

Alaska is not attached to the rest of the USA, so consistency with the
Yukon Territory and British Columbia is equally important.

In the western USA, highway=trunk is not limited to expressways like it is
in Germany and France

On the West Coast, several important State highways are tagged as trunks
even though they are not full expressways, because they are the main road
for a large region. For example, see US 199, US 101, CA 99 and CA 299 on
this map of far Northern California:

https://www.openstreetmap.org/#map=7/40.681/-123.184

Expressways should be tagged with additional details like lanes=, surface,
maxspeed=, expressway=yes, and motorroad=yes

The latter two tags could be useful for rendering if they were applied
consistently.

- Joseph Eisenberg

On Tue, Dec 17, 2019 at 8:29 AM Paul Johnson  wrote:

>
>
> On Mon, Dec 16, 2019 at 6:26 PM Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
>
>> Trunks are rarely expressways in remote parts of the world. In Britain,
>> where this tag started, many highway=trunk roads are not expressways or
>> motorroads.
>>
>
> Are we not trying to remain internally consistent with the rest of the US?
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Alaska Highway AK-2 tagging

[Joseph Eisenberg]

Trunks are rarely expressways in remote parts of the world. In Britain,
where this tag started, many highway=trunk roads are not expressways or
motorroads.

Joseph

On Tue, Dec 17, 2019 at 8:22 AM Paul Johnson  wrote:

>
>
> On Mon, Dec 16, 2019 at 6:18 PM Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
>
>> I would use highway=trunk the whole way for consistency. In Canada the
>> connecting highway is also highway=trunk. This makes sense because AK 2 is
>> linking Fairbanks, the largest city in this part of Alaska, with All the
>> cities in Canada and the lower 48 States.
>>
>
> That's kind of my thinking as to why it should be primary instead of
> secondary (as typical for the US for state highways).  Almost all of it's
> not even paved, it'd be a hard stretch to call it an expressway (trunk).
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Alaska Highway AK-2 tagging

[Joseph Eisenberg]

I would use highway=trunk the whole way for consistency. In Canada the
connecting highway is also highway=trunk. This makes sense because AK 2 is
linking Fairbanks, the largest city in this part of Alaska, with All the
cities in Canada and the lower 48 States.

-Joseph

On Tue, Dec 17, 2019 at 7:37 AM Eric H. Christensen via Talk-us <
talk-us@openstreetmap.org> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> I've noticed that there is some mixed tagging of the Alaska Highway AK-2
> from the Canadian border through Delta Junction to where it becomes a
> divided highway just south and east of Fairbanks at Eielson Air Force
> Base.  Some of the non-divided portions are tagged as trunk while the other
> (majority) is tagged as primary.  The definitions of these two tags are
> similar enough in the U.S. to almost be interchangeable.  Being that this
> highway links many villages with Canada and the City of Fairbanks and the
> speed limit is 65 MPH, I would lean towards this highway being tagged as
> trunk.  By the same definition, I'd probably argue the same for the Richardson
> Highway AK-4
> 
> .
>
> Thoughts?
>
> R,
> Eric "Sparks"
>
>
>
>
> -BEGIN PGP SIGNATURE-
> Version: ProtonMail
>
> wsFcBAEBCAAGBQJd+BStAAoJEIB2q94CS7PR7d4QAMWWtHe8EB3ALRrczWY/
> f3kpdRyYqP8QYVvc1vdvu+j/hAP8NdFGb+aDLx2YLMerDEu4Lt7B0BMN78vT
> LD5629ujwkViIpv8AQt97iWLlruEZOczn44Yhr7KIV6itzmmd9VXfXMs8Kzj
> gOVFdmABwgJd3S/7/tDavgsM49Bh1nvYHkzdUdBwoZ9MuCQbFpoIdj2EPc/W
> Z/XDDssBUcxDIzWaa8kDWB/FlizE+5v6QkgULiB4c7grEbg/7fNziisdYAWp
> lwAqkirEFLsYInrtc80bfkHX0pgb8AtFFZnyDyrY3ijU23Y2Qz5o1qn+4jbS
> PwFCgO6z771vGw3J+RCmKuhOG3fjyW//X0OmtUkAPdiSWKNsPabLlG4/FWib
> phl+2IDx0wlHqYITBEGRGw6pq96chIinlHzdWNmC82/fGI0IXo1Ic9/r3S2v
> Uzr8bwATdLl6mRhYZjAvcLg8yHKblG0PvINjwN4exAthSi+qGsoM5bYDBi8V
> sccUBA0pypUPWCnOVtck4EmMdIJ63b++EoKQ0DUNMGDkpaac6ErKOXDdVt97
> ySbzNzfkkAyproGrwmDLeVQ8gt8aoc0vjlQUZpOoKDcuXgZ7mIhWmwn+4kLL
> WTYYuZn02MVoAsdfbfPB3IyNy9eqmadymFlyNL8AfJC69/0S1TAGLtQFoJjv
> wQlY
> =oEIv
> -END PGP SIGNATURE-
>
>
> ___
> 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: [OSM-talk] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych ? names of international objects

[Joseph Eisenberg]

> for smaller seas, I suggest adding names in all official / main languages 
> ​​of adjacent countries, so instead of "Black Sea" there will be:
Karadeniz Marea Neagră Чорне море | Черно море | Чёрное море | შავი ზღვა

That's fine.

> For larger seas (with more neighboring countries, so the name would exceed 
> the 255 character limit in OSM) and for continents, oceans and poles you need 
> to come up with something else

I'd suggest using the 6 main United Nations languages for the "name=*"
tag of Oceans and Continents: Arabic, Chinese, English, French,
Russian and Spanish.

But there is no perfect solution, and as mentioned, most database
users will want to pick a localized name of the form "name:=" so
these tags should be added.

- Joseph Eisenberg

On 12/5/19, Mateusz Konieczny  wrote:
>
> 5 Dec 2019, 22:12 by to...@disroot.org:
>
>> EO:
>> PL:
>>
> Note that it is an English language forum.
>
> You may ask for help with translation
> from Polish to English at
> https://forum.openstreetmap.org/viewforum.php?id=23
>
> Or you can initially discuss this proposal there,
> other mappers may have a useful feedback.
>
> ---
> the same content in Polish:
>
> Akurat tutaj używany jest język angielski.
>
> Jeśli potrzebujesz pomocy z tłumaczeniem na angielski to możesz
> poprosić o pomoc na
> https://forum.openstreetmap.org/viewforum.php?id=23
>
> Myślę że warto tam też przedyskutować
> ten pomysł, inni mapujący mogąmieć warte uwzględnienia przemyślenia.
>

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

Re: [OSM-talk] Licence of Facebook's derived road datasets? ODbL?

[Joseph Eisenberg]

I don't know anything about the legal aspects, but logically I don't
understand why it is being claimed that facebook releasing a list of
possible roads, which specifically excludes all roads in
Openstreetmap, is not using Openstreetmap data.

I understand that training their algorithim ("AI") on Openstreetmap
data is fine.

But the data that they have released is specifically a list of
features which look like roads on aerial imagery, excluding those
which are already included in the Openstreetmap database, right?

How would anyone use the dataset without also combining it with
Openstreetmap data?

Now if facebook wants to release a dataset of "all things that look
like roads in aerial imagery according to our algorithm (which BTW was
trained on OSM), that's fine.

But they have already gone one step further and then added all
`highway=` features in Openstreetmap to the dataset - in this case by
subtracting those features which are already a very closely aligned to
a `highway` way.

- Joseph Eisenberg

On 11/15/19, Martin Koppenhoefer  wrote:
> Am Fr., 15. Nov. 2019 um 12:41 Uhr schrieb Christoph Hormann
> >:
>
>> Because the basis of most comments made does not seem to be the desire
>> to neutrally assess the situation Rory presents here and its
>> implications.
>> What it seems instead happens here is that people look at the situation
>> and develop a spontaneous reaction in terms of "should this be possible
>> or not" and then specifically search for ways to argue in support of
>> this opinion.
>
>
>
> I am exempting myself from this, because I would not like Facebook to be
> able to use OSM data and not follow the license, but I believe they can in
> this case. ;-)
>
>
>
>> From an engineering perspective the idea that adding OSM data can create
>> a derivative database but subtracting OSM data cannot does not hold up
>> of course.  I can create a polygon data set of the Earth surface (a
>> simple rectangle in EPSG:4326) and subtract an OSM derived data set of
>> the Earth land masses from that to get a data set of the oceans.
>> According to the hypothesis this would not be subject to the ODbL.
>>
>
>
> You are generalizing in a way that is not suitable. What was stated was
> that there must be OSM data (in original or derived form) in the data to
> make the license kick in. In the case presented by Rory, IMHO there isn't
> OSM data in their dataset. It will not be possible to deduct any kind of
> OSM data from their dataset. In your example, you clearly have derived OSM
> data in your new dataset, otherwise it wouldn't be possible to get back to
> the original data (or part of it). The question is not "addition or
> subtraction", but whether there is data from OSM in the data.
>
> Cheers
> Martin
>

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

[OSM-talk] OpenStreetMap-Carto release v4.24.0

[Joseph Eisenberg]

Dear all,

Today, v4.24.0 of the OpenStreetMap Carto stylesheet (the default
stylesheet on the OSM website) has been released. Once changes are deployed
on the openstreetmap.org it will take couple of days before all tiles
show the new rendering.

Changes include:

- Create darker river-color for river & canal areas and waterway lines (#3930)

The color of river, canal, ditch and drain waterway lines
and river and canal areas is changed to #8fcadd (Lch78,21,227)

- Fix rendering of water body labels (#3919)

Restores rendering of water body labels on points (node features)
Fixes rendering of natural=bay to use italic font at all z levels
Cleans up duplicate natural=strait code in water.mss

- Precedence of junctions over POIs (#3915)

Junction=yes, =motorway and man_made=bridge labels now render before
amenity-points
This prevents icons from blocking the display of these text labels

- Remove rendering of waterway=wadi (#3931)

The tag waterway=wadi is deprecated, suggested replacement:
waterway=river/stream + intermittent=yes OR natural=valley

- Move parking to amenity-points layers, change way_pixels limit and
initial zoom level (#3923)

Moved parking features back to amenity-points layers
Changed parking text intial zoom to z14, as planned in PR #3612
Change way_pixels limit for parking icon (750) and text (3000)

- Don't use classes anymore (#3912)
- Convert state & country layers to ST_PointOnSurface (#3920)
- Convert addresses to use ST_PointOnSurface (#3898)
- Apply bbox to part of "addresses" query (#3942)

The 4 changes above are needed to allow use of vector tiles
ST_PointOnSurface is used to generate a point for labeling
Classes are removed, replaced with the layer id

- Documentation updates (#3911) & (#3910), Code clean-up (#3899) & (#3922)

Document inner line rendering, update docker documentation
Clean-up text-placement / marker-placement, remove natural=marsh

Thanks to all the contributors for this release, including Adrian
Piotrowicz (@nexces), a new contributor.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.23.0...v4.24.0

As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues

We would love to have new contributors who might be interested in
solving some of the
many open issues.

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