Re: [OSM-talk] software requirements for OSM Editor: Firefox

2023-10-06 Per discussione Brian M. Sperlongano
This is not OSM's problem to solve.

Ancient web browser slowly becomes unusable = expected behavior.

On Fri, Oct 6, 2023, 7:26 AM Martin Trautmann  wrote:

> On 23-10-06 12:55, Tom Hughes via talk wrote:
> > No it was released in June 2020. October 2021 was the last
> > security patches.
> >
> > To answer the original question there have been any deliberate
> > changes that I know but given the error it's entirely possible
> > that FF has fixed something in what CSP rules it checks for what
> > requests.
>
>
> I doubt that since FF did not see any changes here for some time,
> unfortunately. So it appears to be from an OSM editor's change.
>
>
>
> ___
> 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] Proposed bulk removal of service=driveway2

2023-06-27 Per discussione Brian M. Sperlongano
Since there seems to be community consensus for the removal, I have
notified the main proponent at:

https://www.openstreetmap.org/changeset/130249355

And also opened a matching thread on the community forum.

On Tue, Jun 27, 2023 at 6:07 AM Andy Townsend  wrote:

> On 25/06/2023 00:02, Brian M. Sperlongano wrote:
> > And indeed, nine months later, we see that not only has the work not
> > gotten done, but while we all squabbled away with our pet views about
> > automated editing, we find that we agreed to nothing, and the mapper
> > has quietly continued to add this nonsense tag to the database unabated:
> > https://taginfo.openstreetmap.org/tags/service=driveway2#chronology
> >
> > For the original thread, see:
> >
> https://lists.openstreetmap.org/pipermail/talk/2022-September/087734.html
> >
> Has anyone actually mentioned this discussion to the proponent of the
> tag?  If I've got the right user (and I may not have)
> http://resultmaps.neis-one.org/osm-discussion-comments?uid=741163
> suggests not.
>
> Best Regards,
>
> Andy
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Proposed bulk removal of service=driveway2

2023-06-24 Per discussione Brian M. Sperlongano
On Mon, Sep 5, 2022 at 12:00 PM Tobias Knerr  wrote:

> On 03.09.22 at 12:52, Simon Poole wrote:
> > Anyway IMHO this would seem to make more sense as a maproulette
> > challenge or osmose warning than a bulk edit given the number is quite
> > manageable and at least some of the objects can probably be mapped to
> > one of the "proper" subtypes.
>
> Perfect is the enemy of good and insisting on doing it manually will
> just result in the work not getting done.
>
> I support doing this as an automated edit. Anyone who wants to set up a
> Maproulette task to inspect all ways that were previously tagged
> service=driveway2 is welcome to do so. This way, if the task doesn't get
> done, at least it won't have prevented the removal of a nonsensical and
> confusing value from the database.
>

And indeed, nine months later, we see that not only has the work not gotten
done, but while we all squabbled away with our pet views about automated
editing, we find that we agreed to nothing, and the mapper has quietly
continued to add this nonsense tag to the database unabated:
https://taginfo.openstreetmap.org/tags/service=driveway2#chronology

For the original thread, see:
https://lists.openstreetmap.org/pipermail/talk/2022-September/087734.html
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Intercultural differences / cultural diversity / OSM communication behaviors

2023-05-03 Per discussione Brian M. Sperlongano
On Wed, May 3, 2023 at 3:38 PM Mike Thompson  wrote:

> On Wed, May 3, 2023, 1:00 PM Brian M. Sperlongano 
> wrote:
>
>> I would caution against hyper-simplifying the combativeness of
>> the mailing lists
>>
> I am not sure using a term such as "combative" is going to be effective in
> bringing about the change you desire.   First the term has strong negative
> connotation
>

Whether it's negative is a value judgment, but it's absolutely my
observation. For me, it's descriptive, and I've simply adapted to dealing
with it to get things done on the project. So far, the mailing list hasn't
gone away as a relevant communication space, though I do agree that its
influence is waning. So here I am, dealing with it out of necessity.
However, I absolutely believe people when they express disdain for this
forum.

and second it is non specific.
>

When I send a message to the list, I craft it with several expectations
regarding how it will be received.

I expect that every word of any message I send to the lists may be picked
apart and quoted out of context. I expect that my motivations may be
questioned and that commenters will assume a hidden agenda. I expect
argumentation, criticism, judgment, and accusations that I should have
known better or been aware of a more correct or expected
behavior, principle, or expectation. I expect my
personal/professional/project affiliations, nationality, demographics, and
socio-economic status to be scrutinized in search of bias. I expect threads
to diverge into rabbit holes and meta-discussions. I expect new ideas to be
quickly dismissed. I expect the forest may be lost for the trees and for
hyper-specific details to be nitpicked. I expect that good-faith proposed
solutions to problems may be dismissed without offering alternatives. I
expect to be held to an unreasonable or unattainable standard of evidence
or performance.

That is probably not an exhaustive list, but that's what I mean by
combative, and I don't think that minor changes in word choice will change
the fundamental nature of how people communicate here. I'm sure I'm not
alone in this experience.

And worse, to meaningfully participate here, I often feel compelled to
engage in many of these same combative behaviors that I'm describing to
make my voice heard against this backdrop, so it becomes self-reinforcing.

The people you view as combative probably don't see themselves as combative
> and don't what specifically is causing you to perceive them as such, and
> thus don't know what to do differently.
>

Indeed.

That's why I'm glad that people much smarter than I am on these topics are
exploring the problem.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Intercultural differences / cultural diversity / OSM communication behaviors

2023-05-03 Per discussione Brian M. Sperlongano
I would caution against hyper-simplifying the combativeness of the mailing
lists as "cultural differences". I can think of several German participants
on Slack and Discord that dispel this stereotype.  Similarly, I can think
of several American commenters who are notoriously abrasive on the mailing
lists.  Some have suggested that "open source absolutists" as a group are
the issue. However, we don't seem to have the same complaints about the new
Discourse community forum. Other explanations I've heard suggest that
real-time chat, moderation, and emoji reactions make for a more
collaborative atmosphere for some reason. I don't have the answer, but I
think this thread highlights that there are very real differences in the
various communication spaces that are worth exploring. I welcome any effort
to learn more about how we can maximize people's willingness to participate
in the project. If a meaningful demographic is repeatedly saying that
people's behaviors in communication spaces are reducing participation, I
don't think that should be dismissed or hand-waved away with simple
explanations. Unlike others apparently, I don't especially care who does
that research. If the data, analysis, or methodology are bad or opaque then
that will speak for itself. In the meantime, I assume good faith and await
what the people willing to get their hands dirty and work on the problem
have to say.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Survey about OSM communication behaviors

2023-04-30 Per discussione Brian M. Sperlongano
On Sun, Apr 30, 2023 at 1:06 PM Courtney 
wrote:

> This conversation has opened up important new questions.  Why is the main
> "Talk" channel the only one that is producing pushback? Why is it the only
> one that is producing such a negative tone?
>


> I don't understand the degree of ire and frankly, incredulity that is
> being levied here.
>


> Is that the standard here? Wait for perfection or do nothing?  Is that how
> OSM itself was built? I don't understand the tone or the defensiveness of
> these comments. If the goal is to advance the OSM project, is it better to
> gate keep all inquiries to a suffocating degree?
>

I'd say you've succinctly captured the nature and character of this
particular communication channel and illuminated one reason why so little
chatter happens here compared to elsewhere.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] replace some obviously mistaken surface values by their clear intended meaning

2023-02-11 Per discussione Brian M. Sperlongano
I agree with the proposed edits.

On Sat, Feb 11, 2023 at 12:58 PM Mateusz Konieczny via talk <
talk@openstreetmap.org> wrote:

> Errata: paragraph 4 from the bottom should be
>
> "There is no point in manual drudgery here, with values clearly
> replaceable by better matches."
>
> sorry, I copied wrong bot edit justification template.
>
> Feb 11, 2023, 18:48 by talk@openstreetmap.org:
>
> I propose to replace following surface tags by doing an automated edit:
>
> obvious typos:
>
> `surface=paving stones` → `surface=paving_stones`
> `surface=Paving_stones` → `surface=paving_stones`
> `surface=paving_stones:` → `surface=paving_stones`
>
> different form than standard surface value:
>
> `surface=wooden` → `surface=wood`
> `surface=cobblestones` → `surface=cobblestone`
>
> Polish name to English one:
>
> `surface=żwirowa` → `surface=gravel`
> `surface=kostka` → `surface=paving_stones`
> `surface=gruntowa` → `surface=unpaved`
>
> English vs very close to English but actually different:
>
> `surface=asfalt` → `surface=asphalt`
>
> Edit would be automatic, rerun from time to time, split into small
> changeset by geographic areas and run by
>
> https://www.openstreetmap.org/user/Mateusz%20Konieczny%20-%20bot%20account/history%20bot%20account
>
> Why it is useful? It helps newbies to avoid becoming confused. It
> protects against such values becoming established. Without drudgery
> that would be required from the manual cleanup. It also makes easier to
> add missing surface= values
>
> Why automatic edit? I have a massive queue (in thousands and tens of
> thousands) of automatically detectable issues which are not reported by
> mainstream validators, require fixes and fix requires review or
> complete manual cleanup.
>
> There is no point in manual drudgery here, with values completely useless.
>
> This values here do NOT require manual overview. If this cases will
> turn out to be an useful signal of invalid editing than I will remain
> reviewing nearby areas where bot edited.
>
> And I fixed some manually and they were not a great sign of a problematic
> data.
>
> Yes, bot edit WILL cause objects to be edited. Nevertheless, as result
> map data quality will improve.
>
>
> ___
> 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] Dubious websites added to tourist attractions?

2023-02-02 Per discussione Brian M. Sperlongano
Looks like most of these have been cleaned up but there's a couple left:

https://overpass-turbo.eu/s/1qU8

On Thu, Feb 2, 2023 at 11:13 AM Dave F via talk 
wrote:

> Hi
>
> You may wish to take a look at these changesets by a single contributor to
> decide if  you think these are  dubious websites added to tourist
> attractions.
>
> https://www.openstreetmap.org/user/Aliaksandr%20Kopyshau/history#map=1/37/3
>
> The one in my locale had poor spelling (translation to English?) &
> grammar, took a long time to load & claimed if was copyright of the
> organisation/object that the webpage was about, even though it clearly
> wasn't (It was a bridge owned by the local authority).
>
> They all have similar, yet slightly different URLs
>
> From the wiki:
> The website tag can be used to provide the full URL to the
>
> *official website. *These are clearly not official.
>
> DaveF
> ___
> 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] Should we be mapping transformers and powerlines?

2023-01-18 Per discussione Brian M. Sperlongano
Navigational landmarks while hiking.

On Wed, Jan 18, 2023, 10:17 PM john whelan  wrote:

> Perhaps you could expand on the benefits of mapping them?
>
> Thanks John
>
> On Wed, Jan 18, 2023, 10:09 PM stevea,  wrote:
>
>> I'd like to say "oh, please..." because this seems a bit harsh.  But I
>> understand that people can be sensitive.
>>
>> But this is OSM and I'd like to believe we live in a world that is more
>> free rather than less free.  What's next, do we stop mapping pre-school or
>> kindergartens because they have children?
>>
>> Criminals are going to use maps, yes, that is going to happen.  We
>> mappers ourselves are not criminals for mapping.
>>
>> Map.  Map well.  Criminals will be criminals.  While there are book
>> banning people, librarians are not criminals.
>
> ___
> 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] Use of "Proprietary" imagery to edit OSM

2022-10-30 Per discussione Brian M. Sperlongano
On Sun, Oct 30, 2022 at 9:00 PM Minh Nguyen 
wrote:

> Vào lúc 07:11 2022-10-30, Greg Troxel đã viết:
> > But then the company doing the editing should document which company's
> > imagery and which revision year they are using.   Things should be as
> > transparent as possible, and this doesn't feel that way.
>
> We could ask if the honor code should apply to such a prolific editing
> team. But do we actually have a problem with Lyft fabricating edits? I
> haven't seen evidence of that; it would be quite surprising for a
> company so invested in our project.
>

I have to say, I'm pretty unconcerned with abstract notions of
"transparency" here, as the entire project essentially works on the honor
system.  What I am concerned about is, if an editor is using an imagery
source that a random mapper can't access, they ought to at least indicate
the age of that imagery, to assist the next mapper that looks at the edit,
to understand why an edit may appear different from the current publicly
available imagery.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] razed railways and other things that don't exist today

2022-10-25 Per discussione Brian M. Sperlongano
On Tue, Oct 25, 2022 at 1:45 PM Colin Smale  wrote:

> Are underground pipelines and electricity transmission cables just as
> controversial? They are covered over, built on, and completely unobservable
> from the surface. They may also have been taken out of service many decades
> ago.
>

In the US, generally no.  They are quite infrequently mapped, and they're
tagged as an underground feature when they are.  That's quite a different
scenario from an ostensibly above-ground feature that is not present to the
above-ground observer.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] razed railways and other things that don't exist today

2022-10-25 Per discussione Brian M. Sperlongano
On Tue, Oct 25, 2022 at 4:37 AM Frederik Ramm  wrote:

> in the spirit of friendly collaboration I would say that a limited amount
> of
> stuff-that-should-not-be-in-OSM can be *tolerated*. If someone does a
> lot of good work for OSM otherwise and would really like to record an
> ancient former railroad that ran through where their house now sits - I
> shrug and let them do it.


In my experience, it is more often the opposite situation that happens.  A
mapper, unaware of the lengthy debates on the topic of former railroads, is
mapping her house and removes the bit of abandoned rail currently on the
map in that spot, assuming it is a data error or poor import.  After
all. she's quite aware that there is a house and not a railway at that
location as she has personally surveyed it.  Sometime later, an abandoned
railway enthusiast comes along and angrily harasses the mapper for removing
the bit of railway that quite rightly isn't there. It's been my experience
that allowing enthusiasts to map phantom railways causes far more grief and
contention between mappers than simply drawing a line and saying "we don't
map things that aren't there."
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [Talk-se] highway=trunk in Sweden

2021-01-23 Per discussione Brian M. Sperlongano
Given this, can you comment specifically on an example?  OSM way and photo
below:

https://www.openstreetmap.org/way/199230893
https://www.mapillary.com/app/?focus=photo=WgHheFQe7tkY-5yEbWchbA=57.6457275332997=11.96102332764884=17

Should that way get tagged with any of the following:

1) foot = no
2) motorroad = yes
3) sidewalk = no + shoulder = no

?


On Sat, Jan 23, 2021 at 3:10 PM Ture Pålsson via Talk-se <
talk-se@openstreetmap.org> wrote:

>
>
> 23 jan. 2021 kl. 20:48 skrev Ture Pålsson :
>
> If the wiki is to be believed, highway=trunk is used for roads declared by
> the government to be ”nationell stamväg”, which translates literally to
> ”national trunk road”, except the bits of those that are highway=motorway.
> This, by itself, says nothing about the accessibility for pedestrians. As
> far as I can tell, one must look for explicit foot=* or motorroad=* tags to
> determine pedestrian rights.
>
>
> I should add for clarity that walking is allowed everywhere (on public
> roads) except where explicitly forbidden, which it is on motorways,
> motorroads (E1/E3 here:
> https://www.transportstyrelsen.se/sv/vagtrafik/Vagmarken/Anvisningsmarken/),
> and roads with the ”no pedestrians” sign (C15 here:
> https://www.transportstyrelsen.se/sv/vagtrafik/Vagmarken/Forbudsmarken/).
>
> (And when you leave the public roads, walking is still allowed almost
> everywhere, but then you’re probably not on a highway=trunk anymore! :-) )
>
>
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se
>
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se


Re: [Talk-us] Extremely long Amtrak route relations

2020-11-21 Per discussione Brian M. Sperlongano
It seems that OSM has a an architectural problem with over-large relations?
>
+1

The Tongass National Forest [1] was recently mapped with great detail.  It
comprises most of the Alaska panhandle and all of its islands and inlets.
The relation has 28,000 members and contains over 2 million nodes.  It does
not load on osm.org, and is single-handedly responsible for a 48-hour
increase in the amount of time it takes to render the global tileset.

Meanwhile, on the opposite coast, a few users moved all of Hampton
Roads/Chesapeake Bay, and all of its inlets and estuaries, inside the
coastline [2], in order to speed up the amount of time it takes to render
the coastline and reduce the frequency of users breaking coastline
continuity.  A heated discussion on this continues over on the tagging list.

Personally, I think if the world is complicated, the model should be
complicated.  If the thing we're modeling is large in the world, it should
be large in the map.  It seems that we are increasingly doing things to
simplify the model because certain tooling can't handle the real level of
complexity that exists in the real world.  I'm in favor of fixing the
tooling rather than neutering the data.

[1] https://www.openstreetmap.org/relation/6535292
[2] https://www.openstreetmap.org/changeset/94093155
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-ca] How is protect_class used in Canada?

2020-11-16 Per discussione Brian M. Sperlongano
Great idea.  I just sent out a message to user webfil, who seems to have
initially mapped those lands.

On Mon, Nov 16, 2020 at 8:16 AM john whelan  wrote:

> >I am guessing that some or all of the categories on that list under
> class 7 can simply be deleted.
>
> Have you attempted to contact the original mappers?
>
> We have a few mappers in Canada who have been mapping for more than ten
> years.
>
> John
>
> On Sun, Nov 15, 2020, 23:28 Brian M. Sperlongano 
> wrote:
>
>> Hello neighbors to the north,
>>
>> I have been working to clean up and improve documentation on tagging of
>> protected areas.  I've found that in many cases the documentation on the
>> wiki does not match how tagging is actually done in real life, so I am
>> working to make the wiki more accurate and make the information more useful
>> to mappers.
>>
>> The wiki [1] lists seven different categories that are tagged
>> protect_class=7 in Canada.  I was able to find wikipedia links for a few of
>> them, but the other items in the list looked like generic terms that were
>> just tossed in there by the original author ~10 years ago.
>>
>> So..  what does protect_class=7 tagging mean in Canada?  Does this have
>> real meaning or is it a long-ago forgotten convention?  Since this value
>> does not render on the default map, it is always paired with something like
>> leisure=nature_reserve to force the drawing of an outline.  An overpass
>> inspection [2] shows that this value is almost entirely in Quebec.
>>
>> I am guessing that some or all of the categories on that list under class
>> 7 can simply be deleted.  I'd like to understand how this tagging is
>> actually used in order to make the documentation useful and/or understand
>> what the Canadian consensus for how these values *should* be used.
>>
>> [1] https://wiki.openstreetmap.org/wiki/Key:protect_class
>> [2] https://overpass-turbo.eu/s/10bS
>>
>> -Brian (Rhode Island, USA)
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


Re: [OSM-talk] Your experience in reaching out to Maps.me users ?

2020-11-12 Per discussione Brian M. Sperlongano
Huh. Yes, that's exactly what it did.  Certainly not the behavior I'd
expect.

On Thu, Nov 12, 2020, 11:58 AM Michał Brzozowski 
wrote:

> Hi Brian, the comment was probably made into an OSM Note. Check Notes on
> that OSM user page.
>
> Greetings
> Michał
>
> czw., 12 lis 2020, 17:56 użytkownik Brian M. Sperlongano <
> zelonew...@gmail.com> napisał:
>
>> I downloaded and made a test edit (adding an address to a local POI) with
>> maps.me just now to understand how it works.  It does at least make you
>> log in to OSM.  I entered in a comment on the change, however, I note that
>> maps.me overwrote my user-entered comment with a generic comment in the
>> changeset.
>>
>> On Thu, Nov 12, 2020, 10:27 AM Stephan Knauss 
>> wrote:
>>
>>> Hello,
>>>
>>> On 12.11.2020 10:55, Jean-Marc Liotier wrote:
>>> > Is it just me or are Maps.me Openstreetmap contributors unaware of
>>> > Openstreetmap messages ? Does anyone here have seen Maps.me
>>> > Openstreetmap contributors answer to Openstreetmap messages ?
>>>
>>> I share your experience. Typical maps.me edits are of low quality and
>>> frequently show a misuse of tags, certainly not following to our
>>> community standards.
>>>
>>> I have a very low response rate on comments. Probaly one out of hundred
>>> responds. And I have not seen them going back to fix their edits ever.
>>>
>>> I think OSM API should block edits until email address is confirmed.
>>> And probably re-check the response to emails once a year or switch the
>>> account into read-only mode.
>>> Participating in changeset discussions or using osm messaging could
>>> reset that counter as well.
>>>
>>> Stephan
>>>
>>> ___
>>> 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] Your experience in reaching out to Maps.me users ?

2020-11-12 Per discussione Brian M. Sperlongano
I downloaded and made a test edit (adding an address to a local POI) with
maps.me just now to understand how it works.  It does at least make you log
in to OSM.  I entered in a comment on the change, however, I note that
maps.me overwrote my user-entered comment with a generic comment in the
changeset.

On Thu, Nov 12, 2020, 10:27 AM Stephan Knauss 
wrote:

> Hello,
>
> On 12.11.2020 10:55, Jean-Marc Liotier wrote:
> > Is it just me or are Maps.me Openstreetmap contributors unaware of
> > Openstreetmap messages ? Does anyone here have seen Maps.me
> > Openstreetmap contributors answer to Openstreetmap messages ?
>
> I share your experience. Typical maps.me edits are of low quality and
> frequently show a misuse of tags, certainly not following to our
> community standards.
>
> I have a very low response rate on comments. Probaly one out of hundred
> responds. And I have not seen them going back to fix their edits ever.
>
> I think OSM API should block edits until email address is confirmed.
> And probably re-check the response to emails once a year or switch the
> account into read-only mode.
> Participating in changeset discussions or using osm messaging could
> reset that counter as well.
>
> Stephan
>
> ___
> 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] Use of area/relation icons on boundaries

2020-10-29 Per discussione Brian M. Sperlongano
Hello,

I've been working to improve various pages on the Wiki.  I've encountered
inconsistencies in how the "area" and "relation" icons are used in the wiki
documentation of boundary relations.  It's not clear which of the two icons
should be used when describing tags that may be applied to boundaries (as
opposed to mere multipolygons).  Various pages across the wiki are using
the icons inconsistently, and having consistent pictoral representations
are useful in providing clear documentation and intent to the community.

I wrote up a more detailed description of the problem on Talk:Wiki and
would appreciate community input on which convention should be used:

https://wiki.openstreetmap.org/wiki/Talk:Wiki#Usage_of_icons_on_boundaries
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [Talk-us] [OSM-talk] changeset: 89516909

2020-08-18 Per discussione Brian M. Sperlongano
I see.

Considering that, I've reverted my changes.

On Tue, Aug 18, 2020 at 9:41 PM 80hnhtv4agou--- via Talk-us <
talk-us@openstreetmap.org> wrote:

> i was told i could not use do to licence GIS to.
>
>
>
> Tuesday, August 18, 2020 8:38 PM -05:00 from Brian M. Sperlongano <
> zelonew...@gmail.com>:
>
> All,
>
> I fixed this boundary relation and also one neighboring town (Wheeling,
> IL) using the Cook County, Illinois GIS as the data source, and re-used all
> of the original boundary relations.  Unfortunately it appears that all of
> Cook County needs to be updated to reflect the county GIS data (found here:
> https://hub-cookcountyil.opendata.arcgis.com/pages/boundary-open-data).
> Those census polygons are fairly close, but different.  The two border
> towns I checked just north in Lake County appear to line up perfectly with
> the Cook County data so this might just be a Cook County issue.  This is a
> start but there's lots of work to do there.
>
>
> On Tue, Aug 18, 2020 at 9:10 PM 80hnhtv4agou--- via Talk-us <
> talk-us@openstreetmap.org
> > wrote:
>
> lines no relations yes
>
>
>
> Tuesday, August 18, 2020 7:52 PM -05:00 from Mike Thompson <
> miketh...@gmail.com
> >:
>
>
>
> On Tue, Aug 18, 2020 at 6:42 PM 80hnhtv4agou--- via Talk-us <
> talk-us@openstreetmap.org
> <http://e.mail.ru/compose/?mailto=mailto%3atalk%2...@openstreetmap.org>>
> wrote:
>
> i will fix anything that i missed but the lines are truth.
>
> and it is not a polygon,
>
> As far as I know, boundary relations have to, in effect, be polygons, in
> other words, they have to close.
>
>
> and i broke nothing i fixed what the other guy broke and did it all by
> hand.
>
> The boundary relation (126598)  is currently broken. for one thing, it
> doesn't close at the location of Williamsberg Square residential area.
> ___
> talk mailing list
> t...@openstreetmap.org <http:///compose?To=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 <http:///compose?To=talk%2...@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] [OSM-talk] changeset: 89516909

2020-08-18 Per discussione Brian M. Sperlongano
All,

I fixed this boundary relation and also one neighboring town (Wheeling, IL)
using the Cook County, Illinois GIS as the data source, and re-used all of
the original boundary relations.  Unfortunately it appears that all of Cook
County needs to be updated to reflect the county GIS data (found here:
https://hub-cookcountyil.opendata.arcgis.com/pages/boundary-open-data).
Those census polygons are fairly close, but different.  The two border
towns I checked just north in Lake County appear to line up perfectly with
the Cook County data so this might just be a Cook County issue.  This is a
start but there's lots of work to do there.


On Tue, Aug 18, 2020 at 9:10 PM 80hnhtv4agou--- via Talk-us <
talk-us@openstreetmap.org> wrote:

> lines no relations yes
>
>
>
> Tuesday, August 18, 2020 7:52 PM -05:00 from Mike Thompson <
> miketh...@gmail.com>:
>
>
>
> On Tue, Aug 18, 2020 at 6:42 PM 80hnhtv4agou--- via Talk-us <
> talk-us@openstreetmap.org
> > wrote:
>
> i will fix anything that i missed but the lines are truth.
>
> and it is not a polygon,
>
> As far as I know, boundary relations have to, in effect, be polygons, in
> other words, they have to close.
>
>
> and i broke nothing i fixed what the other guy broke and did it all by
> hand.
>
> The boundary relation (126598)  is currently broken. for one thing, it
> doesn't close at the location of Williamsberg Square residential area.
> ___
> 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