Re: [talk-au] Deletion of informal paths by NSW NPWS

[stevea]



> On Jan 2, 2024, at 3:36 PM, Graeme Fitzpatrick  wrote:
> 
> Thanks, fellas!
> 
> There's my new thing I've learnt today! :-)
> 
> Thanks
> 
> Graeme
> 
> 
> On Wed, 3 Jan 2024 at 09:25, Andy Townsend  wrote:
> On 02/01/2024 22:03, Graeme Fitzpatrick wrote:
> > Only thought there is should the note= possibly be a description= ?
> >
> > Notes are only visible to mappers on OSM, descriptions show to 
> > "everybody" (?) using it downstream.
> >
> >
> This seems to be referring to an OSM note _tag_ rather than "OSM notes" 
> (those red things).  Although not many things claim to process OSM note 
> tags, some do - data in there is just a "public" to downstream OSM data 
> consumers as in a description tag,
> 
> https://taginfo.openstreetmap.org/keys/note#projects
> 
> https://taginfo.openstreetmap.org/keys/description#projects
> 
> Best Regards,
> 
> Andy


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

Re: [talk-au] Deletion of informal paths by NSW NPWS

[stevea]

Because Graeme politely included a question mark, I'll do my best here to offer 
my interpretation, which might actually approach and "answer" to his question:  
whether a note=* or a description=*, each of these data are "in" OSM, as OSM is 
a database.  "Downstream" use cases, like a rendering, an overlay, a particular 
display of OSM data in a particular app on your phone or tablet...these are 
indeed OSM data, but "filtered" through a particular methodology for DISPLAYING 
those data.  So, while the datum of note=* is different than the datum of 
description=*, whether one, the other or both are displayed in any particular 
downstream use case is 100% dependent on whether that "interpretation" 
(renderer, map editor...) chooses to display this, that or another particular 
datum.

In short, BOTH "notes are visible to mappers on OSM" AND "descriptions are 
visible to OSM."  This is dependent, of course, on the editor ("mapper use 
case," if you will) being used, but "data are data."  Choosing whether this or 
that is selected should be driven by which tag to use is more correct, as  can 
be found in our wiki's pages for the note=* tag, or the description=* tag, or 
community usage, such as taginfo numbers or evidence shown in an Overpass Turbo 
query of actual in-the-map data.

I hope this helps!

On Jan 2, 2024, at 2:03 PM, Graeme Fitzpatrick  wrote:
> Only thought there is should the note= possibly be a description= ?
> Notes are only visible to mappers on OSM, descriptions show to "everybody" 
> (?) using it downstream.
> 
> Thanks
> Graeme


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

Re: [talk-au] OSM - NSW NPWS liaison

[stevea]

On Nov 1, 2023, at 10:46 PM, Andrew Harvey  wrote:
> On Thu, 2 Nov 2023 at 16:35, Graeme Fitzpatrick  wrote:
> Tried a test message from an outside e-mail but doesn't seem to have come 
> through.
> 
> Do you have to be subscribed to the list to be able to post to it?
> 
> Yes 

As I say, a low bar.  I like Phil's encouragement for them to "step up" a bit, 
feeling comfortable to edit our map, too.  "Joining," really.

Nice discussion.

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

Re: [talk-au] OSM - NSW NPWS liaison

[stevea]

My two cents.

Our forum and Discord require "accounts" to be registered at the OSM level (via 
OAuth2 by registering for a volunteer Contributor account to OSM) and at "the 
Discord level," something else again.  A mailing list "merely" requires an 
email address as an "account" to be registered with the talk-au mailing list, 
which could be argued (I begin, but offer nothing more than this assertion) 
that this is an "easier" (for "easiest" I add a ?) or at least "lower bar" and 
maybe "preferentially more anonymous" or "less privacy invasive" method, for 
those reasons.

Registering on talk-au doesn't require agreeing to what we agree to to become 
Contributors, "merely" to join a "talking community" about "things Australia 
regarding OSM."  By providing an email address and registering with a mailman 
account, that's both "low-bar" and "fairly sharply focused" at the same time.

A great benefit are many relevant eyeballs who read the "contact us questions" 
which seem to have arisen.

While I'm not, I could imaging myself as an IT person at a National P and 
reading the analysis above, nodding my head, agreeing that it isn't a very high 
bar to jump over to have a chat.  And then, having a chat.

> On Nov 1, 2023, at 8:52 PM, Graeme Fitzpatrick  wrote:
> 
> DWG have received a 
> "Request for a Liaison Officer:
> To enhance the accuracy of OpenStreetMap data pertaining to the NSW National 
> Parks and Wildlife Service"
> 
> This has come up in regard to tracks that they say they have previously 
> requested be deleted (I'm contacting them to confirm just which?)
> 
> What would be the easiest way for them to contact us with questions like this 
> - here / Forum / Discord?
> 
> Question posed in all three places
> 
> Thanks
> 
> Graeme
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au


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

Re: [talk-au] Classifying settlements (Was Re: Filling in blank space (Was Re: Tagging towns by relative importance, not just population size))

[stevea]

Oops, resending to the talk-au list as a whole:


On Oct 5, 2023, at 7:00 PM, Little Maps  wrote:
> City = > 50,000 people
> Town = 5000 - 50,000
> Village = 1000 - 5000
> Hamlet = < 1000
> 
> This kind of query gives a broad-brush pattern of how we can classify places 
> into cities, towns etc. If we can gain consensus on broad cutoffs, we can 
> then explore how services such as health and educational facilities influence 
> outcomes.

A great OT query; thank you!

In USA, and by no means do I mean to be culturally insensitive or seem like I'm 
ramming anything down anybody's throat, we use some rough guidelines at 
https://wiki.openstreetmap.org/wiki/United_States/Tags#Places which overlap 
somewhat.  That wiki, again, deliberately USA-specific (and still emerging and 
getting fine-tuned as of 2023) says:

City = > 50,000 people

Town = 10,000 - 50,000, though some "incorporated municipalities" which are 
smaller than 10,000 (such as the rare state capital which qualifies, like 
Montpelier, Vermont, or other VERY significant "towns" with less than 10,000 
but they contain an important "cultural center" like a university, a hospital 
or other "major amenity" will get place=town as well, this can include "major 
shopping" or something like "the only big box (hardware, variety...) store 
around for a long ways")

Village = 200 - 10,000, though this is flexible (as of 2023), and it is 
emerging as consensus that a village contains at least a small commercial area 
such as a supermarket, a small market (even a convenience store), a bank, a gas 
station (or two, you know, for price competition's sake!) and perhaps a medical 
clinic and/or cluster of doctor / dentist / medical offices.

Hamlet < 200 people

Isolated Dwelling = no more than two households / families.  (Could be a sheep 
/ cattle station for you folks down under).

Trying to help offer perspective, please, though, "you do you" (Aussies do 
Aussies).
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Classifying settlements

[stevea]

FWIW, I find this discussion interesting and excellent.  Please keep up the 
good dialog, which I characterize here as “good work!"
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

[talk-au] Fwd: Filling in blank space (Was Re: Tagging towns by relative importance, not just population size)

[stevea]

Whoops, meant to send this to the list, I sent it to Graeme only.

> Begin forwarded message:
> 
> From: stevea 
> Subject: Re: [talk-au] Filling in blank space (Was Re: Tagging towns by 
> relative importance, not just population size)
> Date: October 1, 2023 at 9:17:40 PM PDT
> To: Graeme Fitzpatrick 
> 
> As an outsider (California, USA) and yet, also an insider (OSM-ing since 
> 2009, and trying my very best to craft agreement, consensus and wiki about 
> this, or at least how we do it / should do it in USA), Ian’s table and 
> suggestions to throw at dart at the board with that and see where the holes 
> are is excellent.  That’s what we (the OSM community in USA) have largely 
> done (or did, maybe eight, ten, twelve years ago) and now we’re doing some 
> adjustments because of the holes and various regional differences.  (And that 
> is absolutely just fine and OK).  These (anomalies, wrinkles, oddities, minor 
> problems to be solved…) are there, but they aren’t so huge they can’t be 
> “adjusted.”  Folks in Oz seem on track to do this, based on my 
> outsider/insider perspective as denoted above.  Keep up excellent discussions 
> like this, try to hammer out something “solid” (or at least “gelled”) into a 
> wiki, or something written, and “go from there.”  This is how OSM works in a 
> lot of senses, but “hamlet, village, town, city…” especially.  For these 
> kinds of discussions, truly, “it takes a village.”  This (edges of place 
> names, with populations and maybe services…) takes shape nicely (in Oz, from 
> what I see and read here), is what I’m saying.  Cheers, there…and keep up the 
> good work via dialog.

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

Re: [talk-au] Putting streams into OSM

[stevea]

Josh (and talk-au list):  My remarks certainly were not meant to be or seem 
like an attack, against you or anybody in particular.  I apologize to you for 
my remarks:  I did not mean to attack you and I am sorry it came across that 
way.  It was a reply to Joseph Crowell's remarks (his "side note," really) that 
relations are "a nightmare to work with within iD and one of the main reasons 
people switch to another editor."  I was concurring with Joseph and wanted to 
strengthen that with my added "positive" by suggesting another editor (JOSM), 
which I consider superior for editing relations (especially compared to iD).

Using iD, I am comfortable editing only a tag or two on a relation, not 
memberships, as I find the latter both presented and manipulation of elements s 
very confusing, even as I recognize that using iD, this is "technically 
possible."  However, as I edit many relations (often large ones, like long 
route=railway or route=bicycle+network=ncn routes), I have also seen many such 
relations "spoiled" by human editors using the software editor iD.  I could be 
wrong here, but I attribute this to iD's particular (peculiar?) method of 
editing relation elements, and compare it to JOSM's, which I find very 
comfortable and intuitive:  JOSM's relation editor is a "modeless" dialog 
window ([1], pioneered by macOS in the early 1980s and remaining to this day in 
many visually-oriented operating systems) that contains two "panes" of relation 
element memberships, buttons to manipulate these, the ability to select from 
the map and otherwise move elements between the map and the relation's 
elements, even a "sort" button (to properly align adjacent elements, like in 
route relations or multipolygons).

Thank you for asking about JOSM and learning it:  there distinctly IS a 
learning curve!  Many people find the initial hurdle of installing a Java 
run-time environment a struggle, but this has been largely "double-click 
automated" for the most part for most popular operating systems.

There is a YouTube video "JOSM Open Street Map Editor for Beginners" [2] but 
better (more comprehensive) is "Learn OSM's" own "course" on this:  "Learn OSM 
step-by-step" [3] which is JOSM-oriented.  Its section on Relations is pretty 
good, in my opinion.  Recall [4] that there are MANY kinds of relations, like 
multipolygon, boundary, route, public_transport...and they are all different in 
their tagging, but they share the similarity of using the relation as a data 
type in OSM.  OSM only has three data types:  nodes, ways and relations, each 
of which can and should be tagged properly.  Many (human) editors in OSM get 
"the basics" of editing nodes, ways and their tags for many common mapping 
tasks, reaching an elementary level (I hesitate to say "beginner") but 
relations are definitely an "intermediate" level of complexity by comparison, 
if not advanced for some people.  The chosen editor really makes a difference 
at how facile one becomes with editing relations.

I'm not looking to "critique" work in OSM, though if somebody does make a 
mistake, and then repeats it (or acts obtuse about learning correct 
methodologies) I will offer them some gentle coaching — if they'll take it.

There are no n00b questions, only n00b answers.  Please, feel free to ask me 
(via one-to-one email, if you like) if you have further questions:  I have been 
told I am passionate, listening, enthusiastic and helpful in my responses about 
OSM (though very rarely, some friction causes a bit of heat, instead of light). 
 I hope I have offered you worthy answers here.

Steve All
Santa Cruz, California, USA


[1] https://en.wikipedia.org/wiki/Dialog_box#Modeless
[2] https://www.youtube.com/watch?v=3Yk8b8SB81o
[3] https://learnosm.org/en/josm/start-josm/
[4] https://wiki.openstreetmap.org/wiki/Types_of_relation

> On May 29, 2023, at 6:24 PM, Josh Marshall  wrote:
> 
> Hey stevea, was this warning on relations due to any particular remark in 
> this thread? ... I feel attacked! ;)  given I've used iD to edit relations 
> quite a bit: I don't usually edit them, but more just adding new ones. Except 
> for re-adding ways when they got deleted from a route, when others changed 
> them. I also wouldn't dream of touching the coastline. :) I've always tried 
> to be very careful to not break anything, but now I'm concerned I've 
> inadvertently done that. (Username is `neomanic` if you want to critique my 
> work.)
> 
> I realise this is a bit of a n00b question, but could you possibly provide 
> some pointers to the better _current_ documentation and resources on 
> understanding relations well and editing in JOSM? Now that OSM has been 
> around for a while, I find it overwhelming to sort through and figure out 
> what i

Re: [talk-au] Putting streams into OSM

[stevea]

I've said all this before:  while editing relations in iD is technically 
possible, it is tedious and difficult in the opinion of many.  A great many 
existing relations have also been broken by people using iD (I can't count how 
many I have personally experienced).  I find editing relations with iD to also 
be a "nightmare," but I don't want to so viciously disparage iD, even as I do 
want to discourage others from using it as a reliable, suitable, comfortable, 
intuitive relation editor.  (It is not).

That said, if you are going to edit relations (from this thread:  streams, 
waterways, coastlines, islands...but also many other more-sophisticated and 
complex-structured data) within OSM, please do so using an editor that strongly 
supports good relation editing.  I use JOSM and recommend it, though I realize 
that JOSM is not everybody's cup of tea, either.

Think:  if you know nodes, ways and tags, but not relations, yet you want to 
edit data properly entered into OSM using relations (and which should ONLY be 
entered into OSM using relations), you must be able to edit relations.  And do 
so well, without more than the occasional minor error.  OSM is not your sandbox 
for practice learning how to edit relations (poorly), though you are likely to 
do exactly that (in my opinion) using the iD editor to edit relations.  The map 
does not benefit by sloppy relations being entered by iD (or any editor).

Learn the basics of OSM.  Next, learn "about" relations (their structure, 
conventions, the differing flavors of them...).  THEN learn HOW to edit 
relations using an editor that supports editing relations well, such as JOSM.  
Though JOSM has a learning curve, it is worth it.  I do not consider iD to be a 
strong editor for relations, these are my opinions.  Thank you for reading.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Waterway data check overpass query

[stevea]

Nice work, everbody.  I include Phil's use of the tool (chatbot mentioned), but 
I do not directly address said chatbot, because it is not sentient.  It is 
merely a tool, well-used in this instance.

Tight snippet of OT there, Andrew; nice.  (make, convert, makefile, 
y'know...yeah).

Is that a light clapping sound / round of applause I hear?
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

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

[stevea]

It seems the big joy in all this is that we are all quite correct.

It isn't so much a conflict as it is "what comes next."  Sure, there are good 
questions that haven't been answered yet, I look forward to those.

OSM isn't a battle.  It is a project.  We grow.

Does it matter what the survey might tell the team, does it matter what the 
realpolitik or composition (its intentions might be...) of the team might be?  
It has formed, Courtney is part of it.  We ARE having this conversation.  It's 
gonna be long, I can tell, part of a dialog we've been having all along, 
really.  Some topics are out in the open more.  Uphill climb, to be sure, 
though lots of us are pedaling.  Oh, and like the song says, "we're an adult 
now."

OSM has toys to share, toys to craft, toys yet to build and more.  We do keep 
learning to share our toys:  it only makes us stronger.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[stevea]

On May 3, 2023, at 11:07 AM, John Whelan  wrote:
> A very accurate summation in my opinion.

> Imre Samu wrote on 5/3/2023 1:03 PM:
>> Courtney  ezt írta (időpont: 2023. ápr. 30., 
>> V, 19:06):
>> 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? 
>> 
>> Hi Courtney,


I agree this is an excellent summation and an important takeaway from it that 
our Etiquette Guidelines may need bolstering in these directions.  In fact, I 
quoted Imre's short essay on our community forum [1] in a discussion about 
trail_visibility that I slightly hijacked off-topic (and have since steered 
back on-topic) about European / German-speaking usage of the word "wasteland" 
(which my US-English ear finds somewhat harsh) versus my preferred word for 
these areas, which I and others might consider "wilderness."

OSM is a global project (somewhat obviously, but apparently often forgotten or 
ignored).  We do well to strive to understand, embrace and even celebrate 
cultural and language differences as part of our greatest strengths.

Köszönök mindent, Imre.

[1] 
https://community.osm.org/t/tag-trail-visibility-proposed-improvements-for-this-descriptive-tag/97865/98
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Talk-GB Digest, Vol 197, Issue 27

[stevea]

I don't totally disagree with Greg's characterization of "unreasonable," as 
"standardized / hashtagged" changeset comments are curt (even a touch rude) if 
they are not super-well-documented (widely vetted, spoken about...) as to 
what's going on, and easily have the ability to hide errors or even be 
potentially harmful (whether intentional or not).  At the same time, John hints 
that entities like a National Trust can be bureaucratic and move in those kinds 
of ways.  Well, yes.

OSM ("Open" being our first name) has a tradition of being transparent.  I do 
like the movement away from "standardized" changeset comments to those which 
are "more representative."  Yes, +1 there.  Do better, as well as is possible 
here.  Really, on all aspects of participating in OSM:  be proud of your 
contributions here, National Trust (Olivia).  OSM can be used as a bit of a 
"chalkboard" (or watercolor easel or wall to be spray-painted...) when we build 
things and they are under construction.  Though, let's be talking to each other 
and agreeing that we're using tags we understand to mean what they say and say 
what they mean.  It is not OSM asking a lot as we ask this, it is asking "the 
right amount."

Get a path (way) or POI (node) "in" the map, first, minimally tagged (even just 
highway=path or add access=no until this is figured out).  Accurate, 
higher-precision location is important, use (e.g. GPS) equipment to the best of 
its abilities (maybe you use a 16-channel satellite receiver unit with high 
trees / dense forest, for example).  You can refine / enrich data in subsequent 
iterations, adding access, route, safety, fee-related, resources / amenities 
(water, restrooms), whatever you like later.  Get "the bones" into the map 
first.  The muscles and skin and hairstyles happen over time.

Entities like a National Trust can use OSM for their purposes, appearing to 
have a toolchain (of rangers and volunteer mappers and a comm path of 
repetition and refinement there) which are on a longer-term.  That's OK, in 
fact it gives plenty of opportunity to explain, document, engage in dialog, et 
cetera.  We're here.  As long as things go "good, better, best" (within a 
reasonable timeframe), it's good.  As the data are vetted as good, they'll get 
better, that's simply how it works.  (Openly, transparently).  You (2nd person 
plural, including Olivia) know what to do; this is small stuff.  Talk to one 
another, be open and better about being open...lather, rinse, repeat.  I think 
we're fine here.
___
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

[stevea]

On Feb 11, 2023, at 9:41 AM, Mateusz Konieczny via talk 
 wrote:
> I propose to replace following surface tags by doing an automated edit:
> ...

To ma dla mnie sens, Mateusz.  (Makes sense to me).


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

Re: [OSM-talk] [talk-au] Adoption of OSM geometry as state mapping base

[stevea]

My local chapter of OSM is in the USA (OSM-US), but yes, I think you (all) are 
on the right approach here:  the "Australia / Oceania Chapter" (I think it is, 
or is called) as a semi-formal sub-community within OSM, or even an "official" 
chapter, is the "first stop" along the way of this sort of "thread the legal 
needle" here, then it might go to the Foundation (LWG, Legal Working Group, I 
believe) as a "they'll figure it out" last stop, perhaps.

So, now at the regional level, maybe at the "global, legal" level (the 
Foundation's LWG) if not fully "resolved" at the regional / Oceania level.

Sorry to be a bit hazy, but it should come into better focus soon; somewhere 
around there, it WILL get resolved.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [talk-au] Adoption of OSM geometry as state mapping base

[stevea]

My local chapter of OSM is in the USA (OSM-US), but yes, I think you (all) are 
on the right approach here:  the "Australia / Oceania Chapter" (I think it is, 
or is called) as a semi-formal sub-community within OSM, or even an "official" 
chapter, is the "first stop" along the way of this sort of "thread the legal 
needle" here, then it might go to the Foundation (LWG, Legal Working Group, I 
believe) as a "they'll figure it out" last stop, perhaps.

So, now at the regional level, maybe at the "global, legal" level (the 
Foundation's LWG) if not fully "resolved" at the regional / Oceania level.

Sorry to be a bit hazy, but it should come into better focus soon; somewhere 
around there, it WILL get resolved.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Tagging Culverts on Roads

[stevea]

On Feb 9, 2023, at 3:00 PM, Graeme Fitzpatrick  wrote:
> On Thu, 9 Feb 2023 at 12:31, Andrew Hughes  wrote:
> And each culvert has a unique asset/ref identification (example Victorian 
> Dept of Transport, Structure Number == SN2252)
> 
> Sorry to be awkward, but do we have permission to use that data? 

Seems a perfectly reasonable question to me.  (No awkwardness felt from here).

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

Re: [talk-au] Brisbane City Bike Racks

[stevea]

On 31/1/23 14:38, James via Talk-au wrote:
>> ...Does anyone have anything they'd like to add, any advice, or any reasons 
>> I shouldn't go ahead with this?

On Jan 31, 2023, at 1:10 AM, Warin <61sundow...@gmail.com> wrote:
> Do, say, 10 local to you and see how it goes. Making a mistake with 10 is not 
> too much of a problem, making the same mistake with 10,000
> is much more of a problem.

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

Re: [talk-au] Brisbane City Bike Racks

[stevea]

Sure, James.  Welcome to OSM.

I would find another (preferably local, though you could go statewide or 
national) more-seasoned OSM user to help you "best interpret" our Import 
Guidelines.  A lot of new users get both enthusiastic (especially about a 
reasonably "bite-sized" import, like yours) and somewhat "tripped up" with 
these Guidelines, often stumbling or getting discouraged, and we don't want 
that.  It might be those Guidelines could use some additional tuning up, but 
they are what we have for now, and someone gently holding your hand as you 
"interpret" them seems it would help or even be best.  Besides, reaching out to 
the greater community (as you have to talk-au just now:  noice!) is part of 
OSM, so getting into that habit early is a good one!

Tenet number 2 of OSM:  (after #1, "Don't copy from other maps")  Have fun!

stevea
California, USA

> On Jan 30, 2023, at 7:38 PM, James via Talk-au  
> wrote:
> 
> Hi All,
> 
> I'm relatively new at OSM and wanted to map the bike racks in Brisbane, of 
> which I am a resident. A few members on the osm discord graciously pointed 
> out the data is available at 
> https://www.data.brisbane.qld.gov.au/data/dataset/bicycle-racks, is under CC 
> BY 4.0, and there is a waiver to OSM 
> https://wiki.openstreetmap.org/wiki/File:BCC_OSM_Waiver_-_Signed_30Aug2018.pdf.
>  I have read the import guidelines, and I'm prepared to spend a lot of time 
> making sure there are no duplicates and making sure the locations match up 
> with the map.
> 
> Does anyone have anything they'd like to add, any advice, or any reasons I 
> shouldn't go ahead with this?
> 
> Thanks,
> James


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

Re: [OSM-talk] Should we be mapping transformers and powerlines?

[stevea]

On Jan 18, 2023, at 7:13 PM, john whelan  wrote:
> Perhaps you could expand on the benefits of mapping them?

I don't wish to sound antagonistic, but that's like asking "what good is our 
map" and expecting the infinite "creative and unexpected purposes" that have, 
do and will evolve from our data to be a complete answer.  It can't ever be 
complete.

Power lines "exist."  They are "in the real world."  Sometimes they are "in the 
way."  (Perhaps I am flying my drone or hang-gliding).  Their poles and towers 
sometimes have wide swaths upon the landscape and make a human, technological 
path wherever they are, they deserved to be mapped.  So do their often-fenced 
substation structures and related infrastructure.  If an owner / power company 
needs to beef up its security, that is little to no concern of mine as an OSM 
mapper.

It's a valuable conversation to have, I'll agree.  I don't like hearing about 
rifle-accurate attacks that take out quite expensive infrastructure with a box 
of well-placed bullets, but that is the world we live in (in some places).  The 
world we map in?  I'll keep on mapping (including power infrastructure, if for 
no other reason than "others make pretty spider-webby renderings" of power 
infrastructure, and I like to look at those).  I'm not a nutter with a gun, I'm 
a mapper.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Should we be mapping transformers and powerlines?

[stevea]

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

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[stevea]

I am “with” Andy here, yet I am also “with" Frederik here:  you might be able 
to get away with this “most of the time,” but when it fails (and it will), 
you’ll be disappointed and perhaps even upset with OSM.  There is simply no 
reason why we should be suggesting or supporting this.  Because it WILL fail.

For that reason, I say “don’t do it.”  And please don’t suggest others should, 
either.  At least once, it won’t end well, and that will be one too many times.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[stevea]

I'll state even more strongly than Frederik just did:  "linking to an OSM 
object by ID and expecting the ID to remain constant is asking for trouble" is 
putting it mildly.  It IS trouble.  All it takes is one single change to one 
single datum and boom, the assumption that doing so can work is proven false.  
I'll offer to be the first to change an ID to do this just on the general 
principle that it proves this is a bad idea.

So, this (linking to an OSM object by ID and expecting the ID to remain 
constant) is a non-starter.  Right here, right now.


On Jan 2, 2023, at 10:11 AM, Frederik Ramm  wrote:
> Hi,
> 
> On 1/2/23 18:57, Sören Reinecke wrote:
>> As OpenStreetMap is playing an important part in the geospatial world, the 
>> OSMF should try to get IETF convinced.
> 
> Until now we've concentrated on making a good map, rather than convincing 
> others that our map is good ;)
> 
> I think that linking to OSM objects by ID is only relevant in the immediate 
> and time-limited QA or debugging context ("does anyone else think way 1234 
> has a problem here") because our IDs are not stable; linking to an OSM object 
> by ID and expecting the ID to remain constant is asking for trouble.


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

Re: [talk-au] 'Named' EV chargers

[stevea]

I mean, people use amenity=charging_station [1], which has a name=* tag.  And I 
think Europe imported a bunch of these over a decade ago.  Maybe it's ME who is 
behind the curve here?  Dian and/or Phil linked this / raised this already.

Regarding what Warin says, OSM just MIGHT be either "a" or "the" preferred 
method of navigating to the charger.  OSM might even aspire to be "real time" 
in the regard, although that seems like an "under evolution now" process.  (And 
some EVs already do this on their on-screen navigation).  It's all how 
dedicated we want to be, starting with capturing the present inventory, 
comparing it to what is known to exist, and "gardening" that into a smooth, 
accurate future.  OSM does this with roads and some POIs already, EV chargers 
are another class of POI.  Getting tagging syntax on these to "established, 
agreed-upon, wide-area standards" is happening.  And will until it settles 
down.  That seems in our near-term or maybe medium-term future, as there is a 
lot of growth and change here.

I think a node tagged amenity=charging_station is a "yes, now, today..." and 
maybe you could agree to add fee=yes (as I don't see a lot of free ones, though 
who knows, with widespread fusion in 50 years, we could dream).  But yeah, 
tagging actual pricing would be like chasing pump data is today at a site like 
gas buddy dot com, with all its wackiness and sometimes / not always 
trustworthiness / updated status.  OSM might get better at "real-time" in our 
future, but for now, I think focusing on "every single one of them on Earth, 
and with a solid syntax wiki-documented so most any mapper could nail one up 
the day its ribbon is cut" is good for us now.  Node, plus good, sensible tags 
(including name=*) and technical stuff like sockets and voltages / amps and the 
operator=* and maybe owner=* tags, then getting into network=* stuff like 
ownership and standardization happens, all while more are built and more vanish 
or are behind private gates or "buses only" or "city corporate vehicles o
 nly" and they might be mapped, but dimmed in some renderers (like restricted 
parking lots are in Carto), because they are non-public.  All of this is 
emerging, all of this will continue to emerge.

I haven't drilled down too much into it, but I recall reading on some wiki 
somewhere (long ago?) that even amenity=fuel could "reveal" one of these (an EV 
charger), even though the "fuel" isn't liquid or gaseous but electrons via a 
socket that might even fit YOUR EV.  So, wider-area taginfo and OT queries 
might continue with comparison against "known to exist" databases / inventories 
of these.  And harmonization of tagging continues.

[1] https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcharging_station
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] 'Named' EV chargers

[stevea]

There is also a "site relation" [1] (a relation with type=site), useful as a 
grouping at a single site.  I'm not saying this is how EV things have been 
done, are or will be, rather something to consider as a "might be."  These are 
relations so it's good for them to be orderly and structured, and "at a single 
site" pretty much goes without saying.

As EVs and their charging stations evolve, grow, move, merge and multiply 
(along with smart parking lots with solar roofs, smarter grids 
infrastructure...), I think there remains a good deal yet of fluidity in this 
sort of tagging.  We do have regional trends, it appears.  We do have fluidity 
in tagging, it appears.  OSM is strong enough and smart enough and fast enough 
to "flow with this" in real time.  Getting big, hugging arms around it all I 
think will take some time, and will smear a bit as it does, though we are 
getting there.

In California, these sorts of things are popping up a LOT, like at "truck stop 
parking areas" and "state Department of Transportation Rest Stops," grocery 
store parking lots and municipal or "corporate yard" lots / shops.  Public 
parking and private parking alike; supply and demand.  Some areas have "smart 
parking" at "just drove into this zone off the freeway and a right turn ahead 
means they have over 500 available parking spaces."  On digital signs that 
update through the neighborhood's main drag, live / in real time.  Entire bus 
networks using electric vehicles.  I often think we choke on our current 
transportation systems, (which often feel last-century), though, slowly and 
surely, it does seem to be getting greener and smarter around here.  There's 
even a nascent hydrogen network.  And in my backyard, "we have ignition" (as in 
net-positive fusion).

>From cold and rainy winter California, Happy Holidays, Happy '23, mates.

that Yank Stevea (in our/OSM's wiki, though not usually or maybe even ever in 
Australia/ wiki)

[1] https://wiki.osm.org/wiki/Relation:site 
<https://wiki.openstreetmap.org/wiki/Relation:site>


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

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

[stevea]

Thank you, Warin, thank you Mike, thank you Zeke:  With Warin's 
"clarifications," I think we move closer to something approaching a reasonable 
way to say this.  I would correct "renders" to "renderers," and perhaps change 
it to "OSM's database and renderers...", but aside from that, +1.

> On Dec 11, 2022, at 12:17 AM, Warin <61sundow...@gmail.com> wrote:
> 
> 
> On 6/12/22 06:39, Mike Thompson wrote:
>> 
>> 
>> On Mon, Dec 5, 2022 at 11:22 AM Minh Nguyen via talk 
>>  wrote:
>> Vào lúc 09:55 2022-12-05, Zeke Farwell đã viết:
>> > That is a good summary, though "Once the OSM available satellite imagery 
>> > does not show the feature" 1) There are other sources that an armchair 
>> > mapper can use other than imagery, such as the Strava Global Heatmap, the 
>> > USGS 3 DEP data (in the US), and GPX data that has been uploaded to the 
>> > OSM server.
>> 2) The term "satellite imagery" also excludes street level imagery, such as 
>> Mapillary
>> 3) Technically some of the imagery we refer to as "satellite" is really 
>> "aerial." 
>> 
>> "Once the feature truly no longer exists and is no longer evident in any of 
>> the available remote sources commonly used to edit OSM, including overhead 
>> imagery (satellite/aerial/drone), street level imagery (e.g. Mapillary), GPS 
>> traces/heatmaps (e.g. Strava), and elevation data (e.g. USGS 3DEP) the 
>> feature can be deleted"
>> 
>> 
> 
> I have abbreviated the above to be;
> "The following tags function is to reduce the possibility of a mapper 
> remapping the feature from existing available sources used to edit OSM, e.g. 
> satellite or aerial imagery, that shows the old state of the feature. Once 
> the OSM available sources do not show the feature, the feature can safely be 
> removed from OSM. Renders cannot rely on OSM preserving physically vanished 
> history. "
> 
> I don't want to use too many words .. so as not to obscure the basic 
> intention. Listing all the possible sources is not necessary... 


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

Re: [OSM-talk] QA tool for finding nameless highways that are armchair-fixable

[stevea]

On Nov 28, 2022, at 5:57 AM, Maarten Deen  wrote:
> Your remark seems reasonable ;)
Thanks, Maarten, I’m chuckling with mirthful laughter here.

> Thing is: this is not meant as a bot, so the usual caveats apply.
That IS an important consideration; thanks for highlighting that aspect.  I 
didn’t know there were / are “usual caveats,” and if there are some, they 
should be widely known, especially by people who discuss these things in a 
place, manner and time such as “this, here and now."

> It just serves as a highlight of "something might be wrong here", like so 
> many QA tools do. What the user wielding the QA tool does with that is his 
> choice.
> Does he automatically correct it? Wrong for OSM standards, but who is going 
> to stop him. Just like who is stopping anyone using a QA tool and 
> armchairmapping something that he really can not see from a distance.

I’m aware of this distinction and again, it is important.  Among others (OSMCha 
[1], there are any number of such tools...), I use Geofabrik's excellent OSM 
Inspector [2], which “merely shows,” (and superbly) rather than “and fixes, 
too."  Perhaps another example will help:  JOSM’s Validator tool gives the 
opportunity (between clicking the Upload button and actual data being uploaded 
to OSM) to review “flagged” problems, some as mild Warnings which could be 
ignored (but shouldn’t be), some as more serious Errors which really ought to 
be solved.  For some of these problems, JOSM is clever enough to “light up” 
(activate in its user interface) a “Fix” button which is smart enough to “take 
the right OSM actions” to actually fix the problem.  This is great when 
available, as it solves the tedium of manually doing something which can be 
automated (so, click the Fix button).  And, as JOSM (and OSM) develop, while 
more and more identified problems are automatically-solvable, some certainly 
are not, and so the Fix button remains dimmed, meaning “these must be fixed 
manually.”  That’s the distinction I’m making here:  I haven’t analyzed Lukas’ 
code to see where / when / whether (and how) he does this (and again, there are 
certainly cases where this MIGHT be possible, and where it is, great, do so).  
I am simply saying “there are times and places where an automated tool CAN fix 
things” (like naming nameless highways…though this really IS tricky, speaking 
from personal experience), and there are absolutely times and places where it 
can’t.  Both tool developers (especially) and also, those who wield such tools 
must be aware of this “sometimes we can, sometimes we can’t” distinctions.

And I’m not saying Lukas has done this, but in this realm (and because I know a 
couple things about “quality” and “mapping” I can say this):  it is all-to-easy 
to glibly make assumptions which are better left not made.  Especially in the 
context of OSM, wider vetting (exactly what Lukas is asking for here) is 
exactly what is needed.  Though, as we get wider input that includes “seems 
reasonable,” I urge caution.  I’ll stop here, as I don’t want to repeat myself.

[1] https:osmcha.org
[2] https://tools.geofabrik.de


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

Re: [OSM-talk] QA tool for finding nameless highways that are armchair-fixable

[stevea]

See, saying “seems reasonable” actually seems reasonable, until one realizes 
one doesn’t truly know.  Ask yourself if others in OSM would agree if “seems 
reasonable” is good enough to meet OSM’s criteria for data entry:  you’ll get 
mixed answers, though a sizable number will say “not really good enough.”  You 
might even have a very high degree of confidence…though, ask yourself if you 
want to navigate (or otherwise rely upon) a map with what amounts to guesswork. 
 That’s how the camel’s nose (of creeping errors, one datum at a time) gets 
into the tent (map).  I mean no disrespect to camels.

I have decades of experience in software quality assurance at top companies 
(Apple, Adobe…), so I have great respect for Lukas’ tool finding / identifying 
errors (emphasis on those verbs), it’s what is done after that which matters.  
Guesswork?  Mmm, no, I’d prefer not.  Our usual “on the ground verify” (or 
otherwise equivalent, like “I already know that”) criteria:  yes, much better.

We’re not quibbling (slightly objecting to trivial matters) here:  these are 
fundamental decisions each and every mapper makes as they enter data into our 
map database.  I strive to keep that quality as high as I possibly can, though 
everything I say here is simply one person’t opinion.  Let’s be careful with 
power tools:  they’re great at finding / identifying errors, whether they can 
“fix” the data after that must be carefully considered case-by-case.


On Nov 28, 2022, at 12:44 AM, Marc_marc  wrote:
> Le 28.11.22 à 00:43, Dave F via talk a écrit :
>> a "high confidence" interpolation, from an armchair or anywhere, will lead 
>> to inaccurate data being added to the OSM database.
> 
> if you have a road in 3 segments A B C and A+C have the ssame name,
> then not only does it seem reasonable to me to add the name on B
> but also the reply "do a survey" is a dogmatic answer: the ground
> does not contain a sign every time osm cuts a way because of a change
> in the number of strips for example.
> So by survey, you will be reduced to deducing that a segment between
> 2 others with the same name, probably also has the same name


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

Re: [OSM-talk] Rent-a-crowd needed JOSM Microsoft store

[stevea]

Yes, thanks much, James!  (For linking "Reporting Infringement to Microsoft").  
I do wonder if simply forking and charging money for existing open-source 
software is an egregious slap in the face to OSM (JOSM developers, especially), 
although I'm not an attorney.  So, I'd urge our LWG / legal-beagles to take a 
look at this, please.

On the other hand, if there is something "value-added" to the fork that 
justifies charging money, maybe it's OK.

> On Nov 27, 2022, at 8:26 PM, James  wrote:
> 
> https://www.microsoft.com/en-us/legal/intellectualproperty/infringement
> 
> On Sun, Nov 27, 2022, 11:15 PM john whelan  wrote:
> You can only leave a review if you download the software.
> 
> Both are JOSM, one is a fork which costs money which goes to the person who 
> created the fork the other is normal JOSM which is free.
> 
> Cheerio John
> 


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

Re: [OSM-talk] QA tool for finding nameless highways that are armchair-fixable

[stevea]

Without wishing to "diss" (disparage) Lukas's tool (I haven't evaluated it), I 
would also urge caution here, for exactly the reasons DaveF outlines.  I'm also 
a partly-armchair mapper, but not (usually, if ever) using Python tools, rather 
knowing that my "armchair-ing" is going to be of high quality because I 
well-understand (and have many years of practice) with OSM's tenets of "on the 
ground verifiability" and such.  I'm also a "real world" mapper (where I "get 
out into the real world" and use a GPS and a notepad/pencil...), which I 
believe should be a prerequisite for being an armchair mapper:  that's how you 
learn and get good at knowing how to armchair-map with high quality and without 
guesswork that can (and usually does) lead to errors being entered.

Especially with going from "no name" to setting a name=* tag to "something" 
(authoritative), this can be a very ticklish undertaking, I've experienced the 
difficulty in doing this first-hand, and I usually "duck out" (end the 
endeavor) as "too likely to introduce specious errors into our map data."

High quality armchair mapping (which does not introduce errors) is not easy:  
it takes practice, knowing what you are doing, likely some deeper knowledge of 
the geographic area, "how things are done (and/or mapped) around there" and 
probably something like "I know quite well how to map bike routes (train 
routes, landuse, forest boundaries..., or whatever you might be mapping)."  If 
you meet all of those "high bar" quality standards, AND you understand what 
Lukas' Python / pyosmium software does / will do, you might want to check it 
out and see if it can be a "power tool" for your armchair mapping.  I've set 
high-quality standards for myself (really, I wouldn't map in OSM if I did not), 
perhaps you should, too.  And then, and only then, maybe use power tools to 
help you, going slow at first, with caution and evaluating your own feedback 
from the map.

I'll be curious to hear feedback from this, too.  Thanks for your efforts, 
Lukas:  I genuinely hope they help our map!


> On Nov 27, 2022, at 3:43 PM, Dave F via talk  wrote:
> 
> Most roads don't have names.
> 
> Any comparison has to be done against an authoritative database or on ground 
> surveying, for the area in which you're searching.
> 
> "where the name can be interpolated from neighbouring ways. This allows to 
> detect and armchair-fix a (small) subset of these cases with high confidence. 
> "
> 
> I have a "high confidence" interpolation, from an armchair or anywhere, will 
> lead to inaccurate data being added to the OSM database.
> 
> Cheers
> DaveF
> 
> 
> On 27/11/2022 20:16, Lukas Toggenburger via talk wrote:
>> Hi all
>> 
>> As you might know, OSM data contains a lot of highway=* without name=*. 
>> Check your region using the following query:
>> 
>> https://overpass-turbo.eu/?Q=way%0A%20%20%5Bhighway%5D%5B!name%5D%0A%20%20(%7B%7Bbbox%7D%7D)%3B%0Aout%20body%3B%0A%3E%3B%0Aout%20skel%20qt%3B
>> 
>> I wrote a Python tool (using Sarah Hoffmann's pyosmium) at 
>> https://gitlab.com/ltog/ohni that is able to detect such highways in a 
>> planet (extract) file and report the ones, where the name can be 
>> interpolated from neighbouring ways. This allows to detect and armchair-fix 
>> a (small) subset of these cases with high confidence. The tool is tailored 
>> to minimize false-positives.
>> 
>> Please check it out and give feedback.
>> 
>> Best regards
>> 
>> Lukas
>> 
>> ___
>> 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] Rent-a-crowd needed JOSM Microsoft store

[stevea]

If choosing which version is "legitimate" (or preferred) is important, and 
"leaving a review" is a (one) method for communicating that, I would underscore 
that if you do leave a review, make very clear how one differs from the other.

On Nov 27, 2022, at 5:33 PM, john whelan  wrote:
> 
> Agreed but some do and currently both have one review each so it isn't that 
> clear which is the official OpenStreetMap editor.
> 
> Even a couple more reviews would help.
> 
> Thanks
> 
> Cheerio John

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

Re: [talk-au] Melbourne - Suburban Rail Loop - Too early to mark as under construction?

[stevea]

Sorry, I meant railway=proposed becoming railway=construction.  The tag 
state=proposed is something used (I do so frequently) in other routes besides 
route=railway relations, like route=bicycle relations.  I apologize for any 
confusion.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Melbourne - Suburban Rail Loop - Too early to mark as under construction?

[stevea]

Catching up on this thread (a bit on the late side, just upgraded macOS from 
Monterey to Ventura) I could say a lot.

In short, I think you've got it right tagging construction=* when you get 
actual digging, paving, power-poles and laying of rail.  I like "well, we've 
got road closures already..." meaning that "we're under construction," that 
sounds right.  And as a segue, "construction" means "funded," what I consider a 
crucial aspect for any project, and anybody rolling backhoes or paving rollers 
is getting paid to do so by a project manager and authority with money for 
paychecks and material.

Where I could say a lot more is when you might say state=proposed.  (When to 
make the transition from tagging "proposed" to "construction" is about as easy 
as reading the previous paragraph).  A shorter version is that OSM is OK with 
tagging state=proposed when "there is funding for the project."  Yet, a LOT 
more than that in OSM gets tagged state=proposed (maybe on the up-and-up, maybe 
somebody needs to redact that tag or some ways).

For example, see the section in our wiki [1] about California's High Speed Rail 
project (the USA's biggest public works project at about US$100 billion and 
controversial / a political hot potato in every way imaginable, although it's 
gotten much better in the last few months as funding gets more certain and 
Phase 1 enters a sort of "middle").  While there were always Phase 1 and Phase 
2, in 2019 (with a new Governor elected) and especially 2020-2 (with COVID), 
the project has been "re-defined" in ways that both explain the delays, cost 
overruns, pandemic pauses, and also break apart Phase 1 into Phase 1a and Phase 
1b in a way that's hard to explain.  The table in the wiki tries to do this, 
and also tries to explain how actual "rail under construction" and "rail 
proposed" differ, mainly by "whether it's funded," but there are aspects of 
"did this pass environmental review" (most of it has), "did this complete 
design work prior to construction" (1b North and 1b South are IN design now), 
and if those two hurdles have been jumped, did it go out to public bidding and 
was a bid actually tendered by the Authority?  For this project, and to keep 
OSM feathers from getting ruffled, we seem to have consensus that it's OK to 
put state=proposed on 1a and 1b, even though they are not quite yet funded (but 
are in design, which is right before bids for funding go out, and the money is 
"more or less promised by the state to be there") — there is odd history.  So, 
"proposed" can be complicated before construction — it certainly is on 
California High Speed Rail.  BTW, expect to start riding this train around 2030 
(Phase 1a "Interim" service), 2031 or so for the initial San Francisco to Los 
Angeles service.

But "construction" is pretty much "are crews constructing?"  Yeah.

Thanks for reading.

[1] 
https://wiki.osm.org/wiki/California/Railroads/Passenger#California_High_Speed_Rail_(passenger=regional)_trains_(CAHSR),_under_construction
 

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

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

[stevea]

Some historical perspective on a project like OSM, its growth, the social 
aspects of "what that means and does to tagging" over time might be helpful.  
The dates and numbers I'm about to offer as examples are wholly illustrative 
(and indicate not arithmetic, but geometric growth, a very powerful force) and 
are no way based in reality because I've "done the research on the actual 
numbers," because I haven't.  I'm simply making a point or two.

Let's say early in OSM's history, oh, 2005 or so, there were 10 mappers 
worldwide who began the first tendrils of rail mapping, and that by 2006 that 
grew to 50.  People in sizes like that can talk to each other and agree on 
things to a 100% level of agreement, or pretty close to 100%.  This is because 
the "problem set" has a small enough size that its "solution set" can be hashed 
out in a few emails, not many kilobytes of wiki, and heads nod in almost 
perfect unison among a relatively small group of people.  If you are "in the 
club," it's easy, and even quite fun!

By 2007 (and, for example, the USA's TIGER Import of hundreds of thousands of 
km of rail) there are 500 active, enthusiastic rail mappers in OSM, and lots of 
work to do, and it feels like maybe "1% of the problem" (of mapping all of 
Earth's rail accurately) has barely had its surface scratched.  On the social 
dimension, this remains manageable, especially as things fragment in to 
different countries, and hundreds of people still might only be a couple, a 
few, or maybe at most a dozen, even in a very complex rail area (like Germany 
or greater Europe):  "localization of the solution space" really does help a 
lot.  This remains doable, but people eye the future and imagine public 
transport and better renderers, and so allow a timeline of a few years for 
these things to develop.  It remains relatively easy, especially if you "remain 
local / regional," and "others (clever ones, busy ones, more-curious ones...) 
"think globally."  OSM is fine.

Fast forward to 2010-11 and now there are many thousands of rail mappers and 
things like PTv2 move from "good ideas" to "coming on strong," OpenRailwayMap 
gets rolling, major differences in how rail all over the world show that the 
problem is large, maybe quite difficult if people are honest, and yet it 
remains manageable as the tools get better and the numbers, while growing and 
at least medium-sized, are not totally overwhelming.

I can go on with real life examples (from this time period of 2014-16-18-20-22, 
and personally, as I've given SOTM talks, one on rail...) and had a fair bit to 
do and say about "rail growth in OSM" in my own country (USA), I've seen this 
growth — geometric growth — and how it has had to cope with rail over the 
one-to-two centuries this transport technology has been around (including ORM 
and OHM as examples of how OSM "maps" it, both logically and literally).  There 
are now hundreds of thousands of rail mappers in OSM, in over a hundred 
countries.  Think of the "social dimensions" of not only "that" but "how that 
has grown and continues to grow."  The amount of fragmentation of understanding 
(especially given humans' many languages and both the limitations of using 
English and the "Balkanization" of isolated language communities) has now 
become quite large...maybe "huge" by some people's estimation.  Logically 
mapping how we have, do and will put "razed" (demolished...all the other 
flavors) of "doesn't (completely) exist today" rail into tagging schemes that 
we all agree upon, especially given that many don't have OSM's now-decades-long 
historical perspective of "how things (like tagging) have grown up w.r.t. rail 
in our project" are now "difficult," but remain explainable and doable.  I 
believe we are up to the task, but it is complex, the geometric growth 
compounds this, so do the relatively long (in software-, data-project world 
sense) timescales, and especially (in a project like OSM), the social 
dimensions (of consensus, multilingualism and so on).  We (all of us in OSM who 
might map rail and other things "that don't exist today") are still "in the 
club," but it is less easy to talk amongst ourselves about why we "do this" 
(but "not that").

And, I'm simply talking about "razed railways" (and a bit more).  It's big and 
complex, and doesn't "shoehorn" (get forcefully or uncomfortably crammed) very 
well into a small box.

Now, please understand there are many, many other topics in OSM which are not 
completely unlike "razed railways" (and why they are an "odd duck" and don't 
seem to categorize well, or need a lot of explaining, or both).

One of my points?  Often, the history of how we got here and oddities of why go 
a long way to explain.  But the natural human desire to understand quickly and 
not necessarily digest all of that makes for quizzical or difficult 
understandings.

Thank you for reading.
___
talk mailing list

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

[stevea]

As usual (nearly all of the time!), I appreciate and agree with your 
well-stated clarifications, Frederik!

___
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

[stevea]

On Oct 25, 2022, at 12:42 AM, Warin <61sundow...@gmail.com> wrote:
a
> Question:
about mapping of old railway infrastructure.

Without "meaning to be mean," I say "oh, no, not again!"  I say it like that 
because OSM has had this discussion many, many times.

I'll be relatively brief here and have at it with a short version, one more 
time.  OSM maps old railway infrastructure because it has very long-lasting 
effects on the land, affecting landuse, transportation patterns and more for 
decades, sometimes for centuries.  OSM (and OHM, OpenHistoricalMap, considered 
by some a "sibling project" of OSM) map(s) these, and OSM documents [1] (even 
with several pictures) that we do, saying "mapping such features is acceptable 
where some (of the infrastructure) remains."  Yes, there remains some 
controversy, the wiki goes to some length to explain what this is, what is a 
borderline case, etc.  But this is a topic which has been thoroughly discussed, 
even as it remains being discussed to this day.

Regarding other things which "don't exist today" which are NOT railways, well, 
those are a separate topic (from railways).

There:  "I didn't fix it..." but I hope that helps.

[1] 
https://wiki.osm.org/wiki/Demolished_Railway#What_is_sufficient_to_map_a_former_railway
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [talk-au] "Wrong" phone numbers

[stevea]

Dialable, darn spell check.

And, in the US, the 1-800 or 1 (800) has become 800 or (800), though not +1-800 
because these are "inward" only, without the preceding 1, though some places 
might still need to dial this, our 11-digit / preceding 1 or 10-digit thing 
(not terribly hard to figure out if you flub it).  Cell phones / mobiles 
"automatically add the preceding 1" if you store / dial 10-digits here 
(representing a US-domestic 10-digit number, a three-digit area/city code and a 
seven-digit "local" number).  Some places require 11-digit dialing with the 
preceding 1.  It's still kind of all over the place whether 10-digit dialing is 
required (it is in many urban areas with multiple area codes) but many 
(especially rural) places allow "local" (omitting the prefixing / area code 
three digits) seven-digit dialing.

That's our "little nightmare," in the USA, every country has one or two or 
three or more of these, it seems.  Especially as technologies continue to clash 
and carriers merge.

Funnily enough, +1-710 was an old "Telex" exchange for the NE USA back in the 
day (1940s-1970s/80s, I think).  A long, long time ago I used to send Telex 
messages for a downtown insurance company.  Old school!
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] "Wrong" phone numbers

[stevea]

Yeah, so this can be confusing.  The 1300 prefix appears to be an 
Australia-only way of dialing what is followed by a six digit number (and as 
there are eight in the mnemonic, the last two are ignored, we get this in the 
states with our 1800 and flavors, like 1888 and 1877 and 1866... "toll-free" 
numbers, which are only "dile-able" from the states).

I think I confused the 710-55... number as real, which it is only a wiki 
example, which I now smack my forehead about.

Really, I'd delete the last two (go with six, not eight, after the 1300) and 
not put any letters in, use the numbers.  Done.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] "Wrong" phone numbers

[stevea]

Solutions abound!

There is a pesky "only in this country toll-free dialing" sort of thing that is 
a number domestically (AU only) and then what appears to be its international 
number, something in NANPA's 710, or what is a moldy-oldy US federal government 
"thing" with exactly one working number (as of 2006).  So, there is some sort 
of "error" somewhere.  Some places that allow these do not allow any 
non-domestic / international way of accessing this telephonic address, there 
isn't any bridging.  We have this in the states, you have this in AU, it is 
different all over the place.

I think phone:AU:mnemonic might be a good start of something.

If you put a plus sign in front of it in your country to say "international 
number" it begins +61.  That's simply "Australia."  It goes up and down from 
there!

I wrinkle my brow at that +1-710-55 number, that's bogosity.  Maybe that works 
in another country or somewhere, but then you wouldn't put a + in front of it; 
that's an "international" phone # notation.  +1-710 (I live in NANPA-land, 
which is that first "1" and know it exists) is a dead-end.  Maybe somebody 
encoded their domestic (to Oz) dialing pattern, I don't know.  But something is 
misunderstood here.

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

Re: [talk-au] Mapping planned light rail routes

[stevea]

To be clear, "infrastructure" tagging as I described it doesn't necessarily 
come first, it (only) would if an existing rail line needs to be entered into 
OSM, then might be repurposed as a light_rail line.  If there is no rail to be 
repurposed, and it is brand-new-from-scratch passenger rail, skip that first 
part and wrangle when it is best to first enter "proposed," then "construction" 
and finally (as ribbons are cut), turning those infrastructure into passenger 
service lines.  For trains and light_rail/tram these are slightly different:  
for trains, you have BOTH a route=railway relation and a route=train relation, 
for light_rail, you can do it with a single relation that represents both the 
physical / infrastructure elements of the rail AND the passenger-oriented 
members of the single route=light_rail relation (like platforms and stop_area 
members).
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Mapping planned light rail routes

[stevea]

On Sep 15, 2022, at 4:38 PM, Graeme Fitzpatrick  wrote:
> Work is due to start "soon" on the next extension of the GC Light Rail route.
> 
> Details have been published about where it will be going, & where the 
> stations will be located, site offices are now appearing & physical work is 
> supposed to start later this year.
> 
> At what stage do we map this, & what as - proposed or construction?

Having a lot of experience with this in OSM (you can see how we do it in 
California here [1] and especially here [2]), the "rules of thumb" that have 
emerged go a lot like this:

• infrastructure tagging (ways tagged railway=rail, or railway=light_rail / 
railway=tram if those are "what is") comes first, then these elements aggregate 
into a route=railway relation (in the USA, these are often called 
"subdivisions," though these route members could be pieces of an industrial 
spur, a logical section of rail tagged usage=branch, a bunch of rail=disused or 
rail=abandoned if you map those...),

• "proposed" tagging (see state=proposed, maybe you like what that displays in 
OpenRailwayMap) comes next, but ONLY when the line / route / service is REAL in 
some sense, like it has gone through final design AND is mostly- or 
fully-funded,

• "construction" tagging really only should start as shovels-are-in-ground and 
equipment is building things,

• and when construction finishes, you can turn the elements of route=railway 
plus stations into (first) public_transport:version=1 route relations, then 
upgrade those with platforms, stop_area and such to version 2 routes (should be 
route=train, route=light_rail, route=tram...again depending on "what is").

The ticklish parts come when you might actually put a "proposed" route in, 
especially if it is widely wanted, the maps of the proposed route are drawn, 
but there is no funding.  Many want to add those to OSM, but many also believe 
they shouldn't be entered until they are "substantially or mostly- / 
fully-funded."

For rail projects, these timelines are often many years, and so the process 
dovetails with some give-and-take among the local / regional OSM community 
about "where about are we?" (in the sense of consensus) about which of these 
stages of "gleam in transport policy department's eye..." to "buy your ticket, 
take a ride" the project actually "is" in some real-world sense.

You folks seem to have figured out a lot about this already "down there," so 
I'm sort of waving from West Coast stateside and saying "we've got some rail 
construction going on here" (2028 Olympics in Los Angeles, California 
High-Speed Rail [3]...), come take a look at how we do it."

You don't want to be "too future-oriented" or you'll ruffle feathers, as you're 
more-or-less saying something exists (in the real world) by putting it in the 
map, when it doesn't (quite) yet.  So be careful with that.  Otherwise, have 
fun / map happy!

Steve

[1] https://wiki.osm.org/wiki/California/Railroads
[2] https://wiki.osm.org/wiki/California/Railroads/Passenger
[3] 
https://wiki.osm.org/wiki/California/Railroads/Passenger#California_High_Speed_Rail_(passenger=regional)_trains_(CAHSR),_under_construction
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Usage of Openstreetmap at EMSINA

[stevea]

Thanks, Ewen:  you have inspired me to dig up his business card (hm, where’d I 
put it?!) and do exactly that.  Yes, I’m sure "a waiver could be signed and 
copyright sorted,” as we really do have open data laws here and I’m sure with 
the rightly-worded request, it could be done legally and without revealing 
whatever might be “privileged.”  There ARE such things (I wouldn’t want MY 
neighborhood’s gate code to be made public if I live on a road where each of 
us, for example, has 15 hectares and shares an access road / gate code).  
That’s not what I’m interested in, but the fact there is a road, and a gate, 
yeah, I could see that making its way into OSM.  I’m quite respectful of 
access=no and access=private, having tagged quite a few of those (after I 
discovered them, which is almost the only way for OSM to do that — well, very 
well / “correctly,” politely / legally, anyway).

What we have (in my little county) is pretty darn good (I think nearly every 
public road and pretty darn close to “most if not all” private roads, excluding 
really well-hidden driveways), but the really, really obscure (usually dirt) 
roads that allow access to “miles way, way back there” are surely missing in 
some cases, and those are like catnip for this mapping cat.  Yes, they are 
private as heck, but I suppose the “for completeness sake” in me craves those 
data.

It’s like finishing a crossword puzzle:  you aren’t done ’til you’re done!

> On Sep 13, 2022, at 2:54 AM, Ewen Hill  wrote:
> 
> Hi Steve,
>   Thanks for the interesting tale. Remember that if you only use the end 
> product through paper maps, mobile data terminals then it is a "black box 
> product" that is difficult to discuss, especially for an area commander whose 
> talents may be in other areas. The Calfire crews I have met have been nothing 
> short of open and accommodating
> 
>Back in 2005/2006, one part of Australia provided 1275 local fire 
> brigades, base maps that they then went out and validated (e.g bridge limits, 
> forestry tracks and private tracks that can be used in a pinch), and 
> returned. Bridge limits are important if you are carrying 3000kg of wet stuff 
> on the back and 2wd/4wd access is also important.  This was then compiled 
> into paper and online maps and has grown significantly since.
> 
>   These maps have around 80 layers compiled from a lot of government data 
> (already available to OSMers) but has a number of layers that OSMers may not 
> need like brigade turn out areas, initial response tables where your house 
> may be a two truck initial response but the house next door maybe 4 trucks 
> due to potential hazards. There is a lot more privileged and operational data 
> that is not suitable for distribution.
> 
>   You should probably be looking at the land management, water infrastructure 
> and transport departments who control the layers we OSMers are interested in 
> to get the waiver signed and copyright sorted.
> 
> Ewen
> 


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

Re: [talk-au] Usage of Openstreetmap at EMSINA

[stevea]

Some USA perspective:  because of where I was, happening to go to a funky 
little mountain organic food store and the proximity of this store to a 
"CalFire" station (sort of two of them, in a regional sense...CalFire being the 
California Department of Forestry, essentially the "state fire department" for 
California — in rural areas where there is no urban fire department), I once 
bumped into what I later figured out is a sort of "lieutenant general" in the 
state fire hierarchy of California — pretty far "up there" for the little 
village I was in.  White shirt, yellow-tin shield, name tag, official state car 
he was getting out of...  I mentioned OSM and what it is and he (I honestly 
think so) looked at me like he didn't know my full name, what I do on the 
project (a fair bit in the county we were both standing in) — but I have a 
feeling he knew exactly who I am — and even what I was about to ask him, but he 
acted very nonchalant.  Super nonchalant.  Very nice man.  I asked him what 
sort of GIS / mapping data the state uses for fire data:  parcels, "back 
roads," the sorts of gates where they have a key or a code (because they are 
the fire department) and it was like I was a guy holding a grenade and asking 
the combination to Fort Knox (where, supposedly, a great deal of gold is locked 
up).

Totally "we don't talk about our map data."  Just shut me down like that.  He 
knew what I was asking, and that I wanted to somehow get it into OSM and it was 
like "talk to the hand, son..." just a total wall of "yes, we might be the 
state and we might have 'open data' (sunshine) laws in California and I know 
you want me to talk about this stuff, but it ain't gonna happen."  He was as 
friendly as could be, gave me his business card and everything, but he shut me 
down so effectively it befuddled me like I've never been befuddled before.

Now, I know for a fact that CalFire has (and uses and updates and improves...) 
some serious, serious map data.  Could I, as a "simple citizen" have access to 
it?  Um, to what again?  What are you talking about?  It was surreal.  The 
answer was either "no" before I asked the question, or whenever I did ask a 
specific question it was "what are you talking about?" in such a skilled way I 
was derailed at every step.  This guy was a master of deception that such map 
data even exists (but of course it does) and he did it while smiling at me like 
the nicest guy at the grocery store, and even gave me his business card.  That 
guy is slick.  I was bamboozled totally.

Moral of the story is that I doubt OSM will ever have access to those fire / 
emergency geo data (and they are necessarily very high quality), and I don't 
know what wizardry by which that happens (as we ARE an "open data" (sunshine) 
state, with "public" data), yet this stuff seems locked up tighter than a bank 
vault.

So, it's interesting how all of this stuff works.  I have found that "some" 
bureaucracies (e.g. county GIS departments) KNOW there is going to be some 
overlap with "their" (our) data and OSM (indeed, I do keep such datasets fairly 
synced, especially as they update / improve).  But for the ultra-high-quality 
emergency-services geo data?  Those seem to be kept on the top shelf of a 
locked cabinet in a room I can't enter.  I suppose that's OK, but in some 
sense, it doesn't feel OK.  I mean, in a "public" sense, those are my (our) 
data.  Are they sensitive, and therefore out of my reach?  Wow, it sure seems 
like it, in a big, big way.

So, sometimes "we use theirs," and sometimes "they use ours" (I've seen and 
participated in the former and noticed that they participate in the latter) — 
which is cool, because over years, the data "get better towards each other" — 
but other times, "never the twain shall meet."  Quite intentionally.  I'm sure 
there are good reasons for this, and it's legal, of course.  And such people 
are trained to "talk about it" by "not talking about it" in that skilled way he 
did, it was amazing.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Should a "trail" route relation be one-way?

[stevea]

Again, you folks are on the right track, here:  keep discussing whether a 
single bidirectional route (with summer-winter alternates) is better, though 
that will require very careful role tag management — OR whether a single 
super-relation representing "the whole route, with all of its complexities" 
might be made up of at least a north, a south, a summer alternate, a winter 
alternate and campsite-spurs (where each of those is a relation, subordinate to 
the super-relation as members) is better.  Could go either way, depending on 
how heads nod.

Either way isn't terribly complex (though the latter might seem a bit scary if 
you haven't done that before, it's actually easier to think about it like this, 
in one sense).  It's quite doable either way (or even another way...but nobody 
has gotten extra-clever and designed "another way," so keep these two basic 
flavors on the table and continue to discuss).  "Maintain-ability" is doable 
with either kind of route, it simply takes some getting used to:  look at other 
routes, especially hiking and I'd say bicycle, though railway, train and 
public_transport routes (their relations and how they are structured) can be 
instructive here.  Big hiking routes are a best comparison.

1000 km is long, so you really want to think about the management of the number 
of members in a single relation if you choose the bidirectional method:  don't 
go over 1000 members (in a single relation) if you can help it and absolutely 
don't go above 2000 no matter what (if so, you do need to break it up into 
sub-relations).

"On the right track" includes talking about this (including fears, trepidation, 
difficulty of management / maintainability...) and carefully walking "steps 
along the way" — I'd say this sort of talking about things right here is 
excellent along those lines.  And yes, if one particular approach doesn't seem 
to be working, change it so it does.  But you'll know when it's working when 
everybody is nodding their heads together saying "oh, yeah, I look at how this 
route is structured in OSM and it makes perfect sense to me" (to the point 
where if it needed a tweak, it would be a relatively simply edit to fix 
things).  That's what you're shooting for.  Not any rank novice being able to 
do this, but the people on this list reading and paying attention (and 
like-minded OSM volunteers at an intermediate- or advanced-level of editing 
relations skill), yeah.  You can agree.

Keep up the good dialog / work, the pieces seem to be coming together!  Don't 
rush things, it's better to dialog first, agree on a well-designed structure, 
and maybe chunk it up so everybody gets a chunk of work to do to make it all 
happen.  Speaking from experience, this sort of "technical community building" 
can be one of the most fun ways we map together!

> On Sep 10, 2022, at 9:38 PM, Ian Steer  wrote:
>> Date: Sat, 10 Sep 2022 16:39:39 +1000
>> From: Warin <61sundow...@gmail.com>
>> To: talk-au@openstreetmap.org
>> Subject: Re: [talk-au] Should a "trail" route relation be one-way?
> 
>> Ideally the GPX file would have at least the trail as a contiguous conga
> line ...
>> with the 'extras' off to the end ... that used to make following it
> easier?
>> 
>> I would think that one file will all the variations (north/south bound,
> season
>> winter/summer) would be quite hard for the users to use and the
>> maintainers to maintain... ???
>> 
> I have mused on the maintainability (since that is dear to my heart), but I
> think having the north/south, summer/winter in one relation will be simpler
> that breaking-out more sub-relations - and I think simplest is best.
> Anyway, what I am proposing is a step along the way to a more complex
> implementation which could be done if this approach doesn't seem to be
> working.


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

Re: [talk-au] Should a "trail" route relation be one-way?

[stevea]

On Sep 10, 2022, at 2:21 AM, Ian Steer  wrote:
>> What would people think about a structure that had a Munda Biddi
...
> - and I would give the winter section, and northbound one-way sections in the 
> main route relation a role of “alternative"

Outstanding!  I step further aside and let you masters craft such a thing, 
marvel from afar, nod my head and smile.

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

Re: [talk-au] Should a "trail" route relation be one-way?

[stevea]

Nice.

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

Re: [talk-au] Should a "trail" route relation be one-way?

[stevea]

On Sep 6, 2022, at 12:36 AM, Warin <61sundow...@gmail.com> wrote:
> The Bicentennial Nation Trail is broken by states (and that is a horse trail, 
> a mtb trail and a hiking trail). It is not well mapped.
> 
> The Overland Track is broken into segments - the 'normal' day lengths for 
> hikers.
> 
> The Munda Biddi could also be broken into segments -
> For example
...

Yes, to sort-of quote myself, "Yes, that's one good way to do it, but I'm sure 
there are other ways, too..." (which would make good sense for well-articulated 
reasons).

I think there might only need to be one "master" relation, that's the one (a 
kind of super-relation) that ties them all together.  Distinctions between 
north and south would be made as sub-relations, "one each" and both in the 
master.  (I'm more familiar with bicycle and public transit routes, not so much 
hiking routes, which have their own peculiarities with the various flavors of 
role tagging the give rises to "alternative" and "excursion"...).

> This makes changes to it easier as you have to change one section and that is 
> then incorporated into each mater relation.

This IS the idea for both "chunking" a big route into smaller components, as 
well as WELL crafting it according to the conventions for that type of relation 
(here, a hiking route):  smaller components are "more manageable" and where one 
(designer / author) decides these edges of structuring can either simplify 
future management as changes occur, or make it more complex because it wasn't 
designed with those changes very well.  Bottom line, take some time to design 
how a large, complex data object in OSM is designed and entered into OSM:  its 
structure does matter, for both purposes of "how does this present to people?" 
(is it easy to understand?, as entered:  does it render and route well?...) and 
"how sensible are the data to manage going forward?"

Let me make the point clearly if I haven't already:  these sorts of "good route 
relation design criteria" are not easy, come with practice, are aided by 
exactly this sort of community discussion (and eventual consensus) we are doing 
here now, and can go multiple directions and still be "widely correct."  We are 
data architects of a sort here, and the way the thing is eventually designed 
and finally put together "only" has to "work," it doesn't have to be "perfect 
under all criteria, for everybody, forever."  Any number of solutions can work 
just fine.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Should a "trail" route relation be one-way?

[stevea]

I forgot to say earlier, so I add here and now:  on really huge routes like 
this — thousands of kilometers long — it makes it more manageable for humans 
(and OSM software like JOSM and other tools / end-use cases like renderers and 
routers) to break up the route into logical sub-components.

I'm thinking of examples I know in the USA, like Pacific Crest Trail or 
Appalachian Trail, where there are either "by state boundaries" kinds of 
"chunking," or designated by Trail Management (I think the PCT uses letters of 
the alphabet to denote segments).

For Munda Biddi, you may want to inquire whether something like this "chunking" 
of the whole trail into smaller segments is already going on "officially," and 
mimic that in OSM.  I will say that dealing with a single relation that 
contains thousands of elements (over 1500 things slow down and get unwieldy) 
are hard to deal with and do recall that there is a 2000-item limit for some 
data structures in OSM.  I don't recommend putting more than 2000 ways into any 
single relation under any circumstances.

I hope all this helps.


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

Re: [talk-au] Should a "trail" route relation be one-way?

[stevea]

On Sep 5, 2022, at 5:25 PM, Ian Steer  wrote:
>> For the "north only" and "south only" segments, I would certainly keep both
>> of these "directional" segments in the one "main" relation, but tagged with
>> role tags:  usually "forward" if the direction of the way corresponds to the
>> direction of travel, 
>> JOSM's relation editor also pays
>> attention to forward and backward directional role tags, presenting them
>> (after a click of the sort button) in a visually clear way.  
> 
> I'm a bit confused here.  Are you saying that even if the ways are in the 
> correct direction (and even have oneway=yes), they should have a role in the 
> relation of "forward" ?  (I don't see forward and backward roles in the wiki?)

If you wish to keep the number of relations that describe a richly-flavored 
route (with north- and south-only segments, summer- and winter-only segments... 
you certainly DO have that here) to a minimum — and your "don't even suggest 4 
relations" indicates you DO wish to do that — then choosing to make the route 
"bidirectional" is the way to go.  I'd say most routes ARE bidirectional, 
whether their author knows this or calls them that or not, especially if there 
are NO "directional role tags" (forward or backward role tags on elements), 
which indicates the members are all "bidirectional" ways themselves.

That said, I'm sort of repeating higher-level aspects of route relation 
practices as outlined here [1].  An earlier section of that same wiki [2] 
describes the forward and backward role tags and how they would be used, for 
example, in this case.  (That wiki also describes how north, south, east, west 
CAN be used as role tags, and as I mentioned earlier, this is frowned upon by 
some, but the wiki notes this is only done in certain circumstances in New 
Zealand, Canada and USA).

So, yes:  I AM saying that making a bidirectional route as you (and I) are 
"heading towards" (as the method by which you implement this route in the 
"efficient" and "easier, with few(er) relations" way to do so, DOES include 
using forward (and possibly backward) role tags on those member elements of the 
relation upon which oneway travel must occur.  Reading the wiki is one thing, 
but you'll want to see other examples of routes that do this (bicycle routes 
are a kind of route where this frequently happens, and so these frequently have 
role tags if they are kept bidirectional).

The OTHER way to do this is to (begin to increase the number of relations it 
takes to FULLY describe the route/routes) make UNIDIRECTIONAL routes, which do 
not have ANY role tags, but are a "straight shot" in the given direction.  But 
you'll need at least two, one for north, one for south (or east and west, if 
those are the predominant directions).  Then, you tie together the two routes 
with a "super-relation," which is a relation containing at least two OTHER 
relations (of the same type).

Sorry if that's confusing; these are fairly complex topics, and you are out in 
the far reaches of the technical possibilities of a relational database (which 
is what OSM is) as we discuss relations, relations with members that contain 
role tags, and especially super-relations.  There are rules and conventions, 
right and wrong ways to do things (if you choose "this" vs. "that") and often, 
several "correct solution implementations."  I think that's true here, and I 
think you are expressing a preference to "keep low the number of relations."  
OK, that implies a bidirectional route (not unidirectional routeS tied together 
with a super-relation, that's three relations at least, though the 
super-relation, simply containing the two sub-relations where all the "work" 
gets done with many memberships, seldom changes once it is established).

So, get to know (from both wiki and real-life examples, I'd recommend both 
hiking and bicycle routes) how bidirectional routes are constructed.  There 
WILL be role tags (usually forward, possibly backward) on those segments which 
are "one-way in THIS direction only on THIS member way," but that's simply how 
these are uttered into OSM.  (Please use JOSM's relation editor to do this, 
again, my opinion as to "the best tool to use," otherwise if you use iD to 
build the relations and their role tags, you will drive yourself crazy.  Some 
iD editors will disagree with me there, that's fine with me).

But with hiking trails [3], there are all those ADDITIONAL roles ("main" is 
assumed if empty, but there are also alternative, excursion, approach, 
connection) which it sounds like for Munda Biddi, there may be some of these 
(like spurs to campsites would be "excursion" and maybe summer or winter 
"branches" would be "alternative").  So, you've got some homework to do about 
the best way to structure this route.  I don't want to seem hand-wavy, or like 
I'm punting on helping you, but what you're doing is pretty advanced "relation 
structuring design," and it could go a variety of ways for a variety 

Re: [talk-au] Should a "trail" route relation be one-way?

[stevea]

On Sep 5, 2022, at 12:23 AM, Warin <61sundow...@gmail.com> wrote:
> Be careful with the automated tool .. you can end up with the route 
> comprising some 'north bound' bits with some 'south bound bits'.

I'm not sure what you mean by "the automated tool," Warin.  I'm only suggesting 
to use JOSM's relation editor window's "sort" button.

> Roles 'forwards' and 'backwards' refer to the direction of travel with 
> respect to the direction of the way - not 'north', 'south' 'east nor 'west'.

Yes, I know.  I'm not sure whether Ian does, though thank you for pointing this 
out, as perhaps I wasn't clear.  My intention was to convey my methodology 
(which works well) and to inspire Ian to discover (using wiki, practice and 
experience) whether it might work for him.  Some Contributors DO add cardinal 
directions as role tags in relations, and that is NOT correct, let's be clear 
about that.  (Sometimes they do this as "placeholders" during route 
construction, but this is not recommended as it is confusing to other human 
editors as these role tags are encountered).

> Route roles are...
> See https://wiki.openstreetmap.org/wiki/Tag:route=hiking?uselang=en#Roles

Yes, specifically for HIKING routes, this wiki and these role tags are crucial 
resources to read and use where appropriate.  Ian, it is essential that you 
read, understand and apply this wiki as appropriate to the Munda Biddi route 
relations in OSM.

> You may find that the renders of hiking/bicycle and horse routes will take no 
> notice of 'forwards' and 'backwards'.

Right:  as the OP mentioned not "know(ing) enough about the potential consumers 
of route relation data..." it wasn't clear to me whether this included 
knowledge of humans as consumers or software like renderers and routers as 
consumers.  Some renderers have "weak" support for role tags, but again:  it is 
most important to get the data "OSM correct," not "pretty for a particular 
renderer" (or router).

> Thinking about this .. and coming from 'public transport' routes ...
> 
> Use 2 relations
> 
> One from 'x' to 'y' (and public transports uses keys 'from' and 'to')
> 
> The other from 'y' to 'x'.
> 
> So you'd have 2 Munda Biddi Trail route relations.. similar to the India 
> Pacific train - one from Perth the other from Sydney.
> 
> This would make clear the north only and south only routes...

Yes, I agree, this is another workable solution, thank you, Warin.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Should a "trail" route relation be one-way?

[stevea]

BTW, I very much recommend using JOSM as your preferred editor when editing 
relations, especially route relations.  IMO, the route relation editor in JOSM 
is superior to all others.  Don't forget to click the "sort relation" button as 
a last step in the relation editor window before you close it, that "neatens 
up" the elements so they connect with each other as best they can (the set of 
elements that are in the relation when you click it), and identifies any 
remaining gaps visually and readily.  JOSM's relation editor also pays 
attention to forward and backward directional role tags, presenting them (after 
a click of the sort button) in a visually clear way.  With practice, once you 
"get it," you won't go back to any other way of editing (especially route) 
relations!

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

Re: [talk-au] Should a "trail" route relation be one-way?

[stevea]

On Sep 4, 2022, at 8:10 PM, Ian Steer  wrote:
> I am a volunteer with the Munda Biddi Trail Foundation, and do my best to 
> keep the Munda Biddi Trail route relation (5810814) up-to-date.  The trail is 
> 1,000km from Perth to Albany.
>  
> There is a child route relation (Munda Biddi Alternate, 8900679) that 
> contains “odds and sods” not on the main route (typically spur trails into 
> overnight huts).
>  
> There are a few sections of the main trail that have alternate routes – some 
> for north-bound/south-bound, and one for summer/winter routes.
>  
> I don’t know enough about the potential consumers of route relation data to 
> answer the following question:
> - should the sections of track with alternate routes (eg north/south, 
> summer/winter) be in the main route relation? – or should I randomly select 
> (say) north-bound and summer routes so as to keep the main route strictly a 
> simple, point-to-point route (and shift the south-bound and winter routes 
> into the Munda Biddi Alternate relation) ?
>  
> My suspicion is that they should stay in the main route relation.

For the "north only" and "south only" segments, I would certainly keep both of 
these "directional" segments in the one "main" relation, but tagged with role 
tags:  usually "forward" if the direction of the way corresponds to the 
direction of travel, if not, either correct that (by reversing the direction of 
the way), or use "backward" as the role tag.  Sometimes, a "backward" role tag 
can't be helped, but that's usually in rather complex scenarios with lots of 
ways.  It is a convention (and "nicety") — not a necessity — to prefer 
"forward" over "backward," but in either case, do what works / is correct.  To 
be clear, these tags mean "on this way in this route ONLY in this direction."

For a route=bicycle, I leave it at that, since most-often-used bicycle 
renderers (I think OCM is, I could be wrong), using forward and backward role 
tags adds "yellow arrows" that make directionality quite clear.  However, for 
non-bicycle routes, this is not as clear, so you might want to change the name 
of the way so it includes a something like "(name), northbound only" (or 
southbound).   This can be controversial, as some believe a name should be 
"name only," but it is still done.  Routers should always process directional 
role tags properly, though your mileage may vary.

For the summer / winter routes, you may want to see if you can coax the 
opening_hours syntax to properly reflect the "time" that these are to be / 
should be used, and also do a rename (suffixing the name=* tag) to make 
"summertime only" clear (again, perhaps with controversy).  You may choose to 
keep these in the "main" route relation, too, or you may choose to break them 
out into a separate relation, where you have relation-wide naming ability 
without re-naming each element way.

In short, you really have essentially full control, though how things are 
parsed by routers (and renderers) can be affected by your choices.  Those 
shouldn't shackle or force you into any particular choice, but do be aware of 
them.  It's better to be strictly "OSM database correct" (and perhaps have a 
less-desirable render or routing because of limitations in a renderer or 
router) than it is to be "pretty" for a renderer, for example (but not strictly 
correct in OSM as a database).

I wouldn't "randomly" select, although you are on the right track when you 
allude that you have a choice to keep a "main route" as a single (usually 
bidirectional) line fully from one end of the route to the other:  you do.  
Making wise choices about how to enter into OSM all the "bristles, branches and 
spurs" of a complex route does come with some practice (and feedback about how 
use cases — including renderers and routers — will process them), but as you 
learn these and get a better feel for them, you can make good choices in how 
you structure the data (elements, tags) in the relation(s).
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Adopting "AU" Prefix on Network tags

[stevea]

It makes a lot of sense.  In the states / USA, we (OSM as state and governments 
rather naturally cleave here for us) "split at state boundaries" all the time 
(as regards to highways and routes).  It is "sane in the long run" I believe is 
widely believed.

Things "come into better focus" for many, is how I might describe it, and I 
think is happening (now, again).  When/as there is "sense in our data" and 
people understand how to build it and use it, our data grow stronger.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Cycle tags on motorways

[stevea]

On Aug 18, 2022, at 12:42 AM, Michael Collinson  wrote:
> Purely as a question: Is there a case for actually mapping the whole cycleway 
> separately as a cycleway? As a cyclist, I like to see what I have in store. 
> Argument for: Well, that is what it is, a dual use cycleway and hard 
> shoulder. And I guess main argument against: Ah, but it is not physically 
> separated and, slightly repurposing Andrew's comment, "you are mapping paint”.

In the case of cycleway=lane, that IS paint, and I (and many others) map these 
all the time.  I see nothing wrong with “mapping paint” like this.



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

Re: [talk-au] Cycle tags on motorways

[stevea]

On Aug 17, 2022, at 8:12 PM, Andrew Harvey  wrote:
> On Thu, 18 Aug 2022 at 12:26, Little Maps  wrote:
> Hi folks, is there any consensus on how to tag cycling on motorway shoulders?
> 
> In some places, the simple tag bicycle=yes (or no) is used.
> 
> We should explicitly tag every motorway with bicycle=yes/no because some 
> motorways allow bicycles and others forbid them.
> 
> In others, the left hand shoulder is tagged as a cycle lane, using 
> "cycleway=lane" or "cycleway:left=lane". Others have  used 
> "cycleway=shoulder".
> 
> In addition to the general bicycle=* access tag, where bicycles are allowed 
> we should tag what kind of bicycle facility is there.
> 
> On the ground, the signs I know (in Vic and S NSW) usually read, "cyclists 
> use left shoulder" and "emergency lane, bicycles excepted". It's not 
> explicitly called a cycle lane in Vic or NSW road guidelines, only that 
> bicycle access is permitted along the road shoulder (as on any other 
> non-motorway road).
> 
> Based on that signage I would say cycleway=shoulder is more appropriate as 
> indicates the shoulder is the designated place for bicycles (as opposed to 
> cycling in the motorway vehicle traffic lanes).
> 
> Though sometimes it's not clear. Markings like 
> https://www.mapillary.com/app/?pKey=382158833064847 are common with marked 
> bicycle crossings which make it look more like a cyclelane than a shoulder 
> cyclists must use.
>  
> In my mind, there's a big difference between tags that imply, "you're allowed 
> to ride on the motorway" (as on any other road) versus, "there's a dedicated 
> bike lane here".
> 
> Yeah agreed, hence the difference between the bicycle=* access tag and the 
> cycling facility cyleway=*.

I have also explicitly set bicycle=yes and bicycle=no tags on certain ways.  
That's another / supplemental way to do something similar.  What we see here is 
that "depending on your use-case or the question you are asking, you might want 
to search for both / some of / all of /with others of... bicycle=* and/or 
access=* and/or cycleway=shoulder tags.  These overlap, have slightly different 
shades of meaning, and sometimes smear together in the minds of mappers.  OSM 
is not perfect and is sometimes complicated.  Good dialog (like here, even 
ASKING of questions) is often helpful.  There can be many answers and 
harmonizing / consensus happens among many.

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

Re: [talk-au] Cycle tags on motorways

[stevea]

On Aug 17, 2022, at 7:23 PM, Little Maps  wrote:
> Hi folks, is there any consensus on how to tag cycling on motorway shoulders?
> 
> In some places, the simple tag bicycle=yes (or no) is used. This is straight 
> forward. In others, the left hand shoulder is tagged as a cycle lane, using 
> "cycleway=lane" or "cycleway:left=lane". Others have  used 
> "cycleway=shoulder".
> 
> On the ground, the signs I know (in Vic and S NSW) usually read, "cyclists 
> use left shoulder" and "emergency lane, bicycles excepted". It's not 
> explicitly called a cycle lane in Vic or NSW road guidelines, only that 
> bicycle access is permitted along the road shoulder (as on any other 
> non-motorway road).
> 
> In my mind, there's a big difference between tags that imply, "you're allowed 
> to ride on the motorway" (as on any other road) versus, "there's a dedicated 
> bike lane here".
> 
> FYI, this overpass turbo query shows some common tagging options in different 
> colours: https://bit.ly/3TaYR8P
> 
> Any thoughts? Thanks, Ian

It's a good discussion, you hit a lot of highs with directly-pointed questions. 
 I have tagged cycleway=shoulder on some of our "expressways," not motorways.  
Here (California), motorways, which we call freeways, quite distinctly prohibit 
bicycles, except brief segments where they are allowed for "sole connectivity" 
reasons and strict regulatory signs ("Bicycles Must Exit") are found — these 
are quite rare.  Though I know of such roadways, I would tag cycleway=shoulder 
here (I haven't done so, or maybe only once where I would not dare ride even as 
I know it to be "technically legal" for those bold, adult, experienced...enough 
to bike it).  On some expressways, there is a very clearly delineated (most 
frequently with stencil of bicycle / "BIKE LANE" paint, sometimes 
"base-bendable reflector tags" every 10 meters or so at intersection merging 
with autos zone / shared-lane, rarely with "raised dots" only, to mark a 
cycleway lane...) "Bike Lane," quite succinctly tagged cycleway=lane.  There 
are newer, various flavors in urban areas in California to use different colors 
here (green paint which entirely fills portions of some bike lanes).

I would encourage to map segments which are explicit (bicycles can, bicycles 
cannot) with explicit tags.  Easier said than done, I know, but when tags "hew 
close" to what "is" (on the ground) or "signed" or (yet a bit weaker) "what is 
known to be legally allowed here" then "tag it so."

OSM has really proliferated a myriad of quite exact tagging for cyclists in 
urban areas with congested bicycle traffic and infrastructure; this is true.  
Yet for the simple "this (often outback) highway allows bicycles in the 
shoulder, under certain conditions..." it can be vague to tag that.  If 
shoulder, tag shoulder.  That's like a bit of watercolor that can be "richened 
up with deeper color" (with more specific tagging) if need be.  It takes a bold 
cyclist to cycle a cycleway=shoulder, especially as it is known to be either a 
motorway (freeway here, bikes basically don't happen here) or an expressway.  
An expressway with a cycleway=lane?  Sure, you have to be "an adult rider" to 
do that, but those lines of paint are much saner (for an experienced cyclist 
accustomed to accompany higher-speed auto traffic in a nearby lane) than a 
rude, raw shoulder on a motorway or expressway.

As usual, "tag your best."  Those are my thoughts.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Oz tagging of speed cameras

[stevea]

Graeme:  You are possibly / likely correct about assumptions regarding size 
(I'm not local, I haven't seen the devices, I don't know of any standardisation 
/ competition-in-the-traffic-camera-marketplace you have in Oz).  However, 
also, you might 'not' be correct about assumptions regarding size.  Please be 
careful.

Speed cameras are notoriously "cat-and-mouse" about where they are, how legal 
they might be in the jurisdiction, what technology is available / deployed, how 
many decoys there might be (obvious or not), what sort of categorization based 
upon visual elements of a box on a pole there might be  Careful, is all I'm 
sayin'.

Sometimes things are as they appear to be, sometimes a bit more care must be 
taken.  Speed cameras are in the realm of "take a bit of care to get it right." 
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Adding river crossings to Guidelines "road quality / 4wd-only"?

[stevea]

On Aug 10, 2022, at 11:45 PM, Graeme Fitzpatrick  wrote:
> I wasn't familiar with "Drop-Bears" (until I looked up that good-natured hoax)
> 
> Neither was this lady! :-)
> 
> https://www.youtube.com/watch?v=EwmoiUrC02g

I have no idea how everybody (except for the British reporter, of course, until 
the joke was over) kept a straight face through those couple of minutes.  
Especially the koala.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Adding river crossings to Guidelines "road quality / 4wd-only"?

[stevea]

On Aug 10, 2022, at 11:32 PM, Graeme Fitzpatrick  wrote:
> Imagine how Australian you'll feel being the one to add the row to that wiki 
> with "Crocodiles are present."
> 
> Snakes, spiders. sharks, Drop-Bears ... :-)

Oops, I meant hazard=leeches (not hazard:leeches).  Gotta get the syntax right. 
 So, hazard=wild_animals (or, I'd be OK with hazard=crocodiles, as the former 
is a bit vague).

I wasn't familiar with "Drop-Bears" (until I looked up that good-natured hoax). 
 Lotsa fun in this project, and there's nuthin' wrong with that.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Adding river crossings to Guidelines "road quality / 4wd-only"?

[stevea]

On Aug 10, 2022, at 10:05 PM, Andrew Harvey  wrote:
> The hazard tag https://wiki.openstreetmap.org/wiki/Key:hazard seems like a 
> good fit to warn of crocs.

Agreed:  I shared some input with the author on this tag.  It is deliberately 
"open-ended" with rough/loose categories right now of area hazards, traffic 
hazards, water (-related) hazards...with the latter being both likely a good 
sub-category for crocs (I could be wrong, though I think they are aquatic), as 
it already has hazard:leeches (and I quote from its Description column):  
"Leeches are present."

See the wiki, stroke your chin, talk to a fellow mapper (or three) about how 
they might like to map crocs, perhaps add a row of hazard:crocodiles to the 
wiki and tag accordingly (Bob's your uncle).

Imagine how Australian you'll feel being the one to add the row to that wiki 
with "Crocodiles are present."
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Tagging silos?

[stevea]

I'm not saying it should, but it could:  somebody sees both usefulness to 
specify and usefulness to tag (heavily implying serious usefulness to "seeing 
the bigger picture of data" after they are entered and become geospatial) and 
makes a proposal that craftily "gathers" silos together into one of many 
flavors (what are we at, 19 different types?) of OSM's relations.  (A 
relation's type=* key).  I might imagine type=collection could be a good start, 
then those sort themselves into various agricultural "divisions" or so...and 
then somebody starts a thread on the tagging mail-list about "silo groups" (I'm 
simply making that up in a fantasy) and people begin to back-channel a 
proposal, which gets traffic on its Talk (Discussion) page and might get voted 
on and Approved... and used in the real world / real map as "sane, well 
specified, harmonious, agreed upon with a certain amount of consensus..." and 
so on.

How very OSM that would be.

At this point in time, I'll say "rather nice as entered" (as a little cluster 
of silos) and whoever wants to dream of mapping silos in some fancy fashion 
certainly could.  And might someday.  Bean Growers Australia, I wave from 
California!

Such a wonderful plastic map...uh, I mean database, we have here.

> On Aug 10, 2022, at 6:51 PM, Phil Wyatt  wrote:
> 
> They look fine – I have also done one set as ways which is the other 
> alternative
>  
> https://www.openstreetmap.org/edit#map=20/-26.55069/151.83033
>  
> Cheers - Phil
>  
> From: Graeme Fitzpatrick  
> Sent: Thursday, 11 August 2022 11:08 AM
> To: Ewen Hill 
> Cc: OSM-Au 
> Subject: Re: [talk-au] Tagging silos?
>  
> Tried the first group of them: 
> https://www.openstreetmap.org/#map=19/-26.55053/151.83027
>  
> Still not convinced that individual is the way to go?
>  
> Thanks
>  
> Graeme
>  

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

Re: [talk-au] Mapping "secret" facilities?

[stevea]

On Jul 27, 2022, at 1:02 AM, Warin <61sundow...@gmail.com> wrote:
> On 27/7/22 17:13, Mateusz Konieczny via Talk-au wrote:
>> is it clearly signposted as cannabis factory farm at its location?

I sincerely doubt this would ever happen, but if it did, you can bet their 
security is much, much better than any bad intentions you might have.  BTW, 
“mapping” (per se, as we do in OSM), is not a “bad intention.”  (I’d say it’s a 
GOOD intention).

> No. A friend of mine went past such a farm on a back road... and was pulled 
> over for questioning.. just for going past. There are no signs nor any 
> publicity about there existence. They don't want people to know as as to stop 
> some people coming by to take some of the crop.

If the “farm back road” were private, I can see a landowner / their agent being 
able to do this or something like it to trespass you.  If the road were public, 
only police could “pull you over for questioning,” and besides, this is 
bullshit, as you had committed no crime or traffic infraction.  Who cares if 
“they don't want people to know”?  There is a farm there:  map it.

I don’t follow Warin’s story about what his friend did or what happened; 
something doesn’t sound right about that.

> Simply map it as farm land. The crop may change .. e.g. crop rotation.

You could.  But if it weren’t posted, but, say, you personally know of it 
otherwise, and it is verifiable (perhaps you could look in local records to 
find a business license or something like that), you could still map it.  It 
feels like there is a lot that isn’t being said here.  Graeme put “secret” in 
quotes, but there really isn’t such a thing when it comes to mapping, am I not 
correct?  If YOU know "something is right here,” and it is verifiable, there 
aren’t any secrets.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Mapping "secret" facilities?

[stevea]

On Jul 26, 2022, at 6:05 PM, Graeme Fitzpatrick  wrote:
> On Wed, 27 Jul 2022 at 10:42, stevea  wrote:
> We map cannabis facilities in California; cannabis is legal here.
> 
> Production facilities, or only shops?

I have mapped several shops, as their location must "thread careful needles," 
like being so many thousands of feet away from schools and such, so they are 
necessarily located in what are relatively out-of-the way places.  If I knew of 
"industrial plants (for cannabis)" — heh, see what I did there?! — I WOULD map 
them, but again, I might not necessarily include a name=* tag, especially if 
they were quite closed to the public (as most "industrial plants" are).  My 
point is, they are legal, they are not "top secret" (like a military facility, 
for which we have specific tagging, and laws-on-the-ground which REALLY guide 
what is legal, expected human behavior regarding these facilities).  And again, 
if they are especially strict with access=no (as I imagine they would be, with 
"upped" surveillance like gates, guards, fences, cameras...these are mappable, 
too), then include an access=no tag to underscore that "they are there, they 
are not there for YOU."

> I am of the opinion that "if it is in the world, it can be mapped."  There 
> are things that people say we SHOULD not map, and I have even seen some 
> well-reasoned arguments which cause me to nod my head. 
> 
>  Yeah, discussion also on Discord is concerning Verifiability - is there a 
> sign out the front which says what it is?

I've had discussion about this regarding key:owner on our wiki. [1]  If it IS a 
sign (plaque, building dedication stone...) that asserts actual, current 
ownership, that is certainly definitive, and has every reason to enter OSM.  
But "government records" (I argue in the Talk page of that wiki) can also be 
used, as long as this practice doesn't hew too closely to turning OSM into a 
"cadastral-like database of land- and business-ownership information."  I mean, 
we map fast_food restaurants (businesses, yes, these ARE open to the public), 
along with their opening_hours, website, phone_number...etc., so we certainly 
can map OTHER businesses.  Even those not open to the public (it's good as we 
denote that).  But again, a polygon of the outline of the building tagged 
building=industrial is at least a start, and such "little starts" are 
frequently how good, verifiable, reliable data are "built up" (over time) in 
OSM.

> (I note with some amusement that you cay "Cannabis 'plant'"
> 
> LOL! :-) 

Once in a while, mild linguistic ambiguity can (and does) give rise to mild 
amusement.

[1] https://wiki.osm.org/wiki/Key:owner , and see its Talk page, too.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Mapping "secret" facilities?

[stevea]

On Jul 26, 2022, at 5:31 PM, Graeme Fitzpatrick  wrote:
> Have just spotted a Note where an anonymous user has given company name & 
> address details for a Medicinal Cannabis plant.
> 
> Checking to confirm details & found a news article that said, yes, the plant 
> is near Mildura, but "Due to the nature of its business, however, it has a 
> secret location and isn’t open to the public." 
> 
> The company involved doesn't have the plant address listed on it's website.
> 
> Should we map it?

We map cannabis facilities in California; cannabis is legal here.

I am of the opinion that "if it is in the world, it can be mapped."  There are 
things that people say we SHOULD not map, and I have even seen some 
well-reasoned arguments which cause me to nod my head.  For example, I once 
mapped some hiking trails (as access=no) on closed-to-the-public land.  I was 
asked by the owner (land steward, really; ownership is a "public land trust") 
to remove them, as he convinced me that "these trails are still under 
development, they are not yet 'real' trails, but will be after they are 
developed and the land is properly opened to the public."

You might choose to use "more generic" tags, like building=industrial and 
"leave it at that."  (I note with some amusement that you cay "Cannabis 
'plant'" and that could be a manufacturing facility, or a rooted dicotyledon 
growing in the earth — I assume the former).  Adding something like 
access=private couldn't hurt (if true).
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] definition of PSV (Public Service Vehicles) in Australia

[stevea]

> On Jun 26, 2022, at 6:46 PM, Dian Ågesson  wrote:
> Unfortunately bus lane restrictions are not the same in each state and 
> territory. 
> https://wiki.openstreetmap.org/wiki/Australian_Tagging_Guidelines/Transportation.

> As there isn't a consistent delineation about what counts as a public service 
> vehicle in each state and territory, it'd probably be better to err on the 
> side of specific access tagging rather than relying on a state/territory 
> default. For David's case, I think a tag of taxi=yes would be prudent.

I suspected as much, having recently read exactly that wiki. OK, at least we've 
"talked about things" and I think it's largely / all sealed up that Australia 
needs "certain packaging tape" to wrap around things (as they are). That's not 
terrible, and it seems you have a place to document these "trimmings." So, 
yeah, great. See you in the wiki.  Maybe a link to this thread couldn't hurt.  
It's all good.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] definition of PSV (Public Service Vehicles) in Australia

[stevea]

On Jun 26, 2022, at 6:24 PM, Ben Kelley  wrote:
> I'm not sure if this helps, but a "bus lane" allows buses, taxis, bicycles 
> and hire cars. A "bus only lane" allows only buses (not taxis and hire cars). 
> (Neither allow rental cars.)
> 
> The psv wiki page suggests tagging individual types if necessary, but implies 
> that a taxi is a PSV.
> 
> https://wiki.openstreetmap.org/wiki/Key:psv
> 
> I think you should probably put taxi=no for a "bus only lane" but not for a 
> "bus lane".
> 
> IANAL but I'd guess that ride share services are not taxis in this context.

I'd say a "municipal" taxi, that is, one regulated by municipal and/or state 
law, often requiring a "medallion" (an "award" by the driver that bonding, 
knowledge...requirements are met, often in accordance with state law) IS part 
of what might be allowed in a "bus lane" (though, I agree not a "bus only" 
lane). However, an Uber/Lyft/whatever, no.

Thank you for understanding we are not talking about "cars for hire" what in 
the USA is called a "rental car."

Good to have international dialog about this; some of the issues are a bit 
subtle.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] definition of PSV (Public Service Vehicles) in Australia

[stevea]

On Jun 26, 2022, at 5:57 PM, David Vidovic via Talk-au 
 wrote:
> In regards to PSV (Public Service Vehicles), I understand this encompasses 
> buses/coaches.
> 
> For a "bus only" way such as a bus bay, I see common tagging [access=no] + 
> [psv=yes] used.
> 
> Does anyone know if a Taxi is considered a "public service vehicle" and 
> therefore able use the busy bay way? Or does [access=no] inherently prevent 
> this and it would need a separate [taxi=yes] tag?

It might be controversial to say so, but "taxis" meant (until maybe a decade 
ago, with the uprising of the Uber's of the world, which are, in many places, 
"not de jure taxis" but are rather "de facto taxis") a legally-regulated 
car-for-hire (not "rental, YOU drive," rather "hail one" (or solicit a ride for 
a fare at a taxi stand)).

A bus is clearly a "municipal vehicle" (public service vehicle, or some 
widely-agreed upon flavor).  A "taxi," well, if it isn't what we used to call a 
"yellow cab" (sometimes municipal, sometimes a "charter contract" 
medallion-holding, regulated by both state- and municipal-level government 
oversight / regulation), it might be an Uber or Lyft, or whatever.  I realize 
that's a "rabbit hole" down which this tag / semantic goes, but I don't want 
the distinctions to be ignored.

As to whether "bus bay" includes "taxis," well, I wouldn't say so.  "Around 
here" (northern California, USA), we have "separate" infrastructure for these:  
different lanes, different rules, different expectations by the users of the 
transportation service.

Careful:  this is a wide semantic.  I realize I cross the "in the States" and / 
"down under" boundary (being from USA, yet posting to talk-au), yet, OSM is a 
global project.  True, you can make regional exceptions to tagging, but I'm 
just saying:  be careful.  So far, so good.___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Well I bought an L1/L5 Mouse GPS

[stevea]

Again, a recommendation to deal with imagery offset "smears:"  start with the 
"street network" (grid, whatever) first.  That "lays down the meridians" as 
accurately as you know with minimal effort right down to the centerlines of 
multiple-lane tarmac.  The small (er) stuff like buildings, those follow 
"later."  Otherwise, you are pretty much chasing your tail.

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

Re: [talk-au] Well I bought an L1/L5 Mouse GPS

[stevea]

On Jun 22, 2022, at 6:45 PM, Alex Sims  wrote:
> I’ve now got a relatively (<$100 + postage) Mouse GPS. It is amazingly 
> accurate. That’s the good news.
>  
> Now I can see a whole bunch of streets, buildings etc out by 1-5 meters as 
> *some* features were traced without correcting the image offset. Also found 
> my cheap GPS and an OSX machine are not a great combination. GPSD gets 
> confused and ends up with mojibake most times. Virtual serial port is fine in 
> screen, QGIS etc.
>  
> Still fun

I don't know the specific product, I'll look it up (and I'm in the States, 
maybe I can't get one, or only with difficulty, not worth shipping / taxes / 
duty / customs, whatever).

Image offset-derived "smears" in OSM's data can be a pain in the neck, 
especially as you get "multiple drifts" from a number of (imaging) sources.  
However, 1 to 5 meters, today (2022) isn't terrible.  And over years (yeah, 
sorry for those in a hurry), I have noticed "this gets better."  It's an 
ongoing effort.  Think of it like a slow motion countdown to zero, but like 
Zeno's Paradox, never really quite gets there.  Too, precision can be in the 
eye of the beholder.  1 to 5 meters?  Hey, you're not lost, perhaps a bit 
"smeary" but not lost.

JOSM does have a way to "imagery offset" differing layers, though I find it's 
only a temporary solution and try to keep these at 0,0.  My recommendation is 
to not try to do too much correcting all at once.  Chip away at it.  The data 
do get better.  Slowly, surely.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Country homesteads?

[stevea]

I'll start and finish by saying "be careful."

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

Re: [talk-au] Country homesteads?

[stevea]

Truthfully, I’ve seen it both ways:  that’s partly why I asked (somewhat, but 
not completely rhetorically) “which (one of the two landuse tags) renders?”  
(Farmland or residential?)

I wasn’t tagging for the renderer, I was tagging according to the wiki, and 
only after many years after that tagging style was documented in our wiki did I 
even start to tag like that (so in fact, as a result, only rarely and 
recently).  Tagging styles do change, that is another point of my post and 
“farmyard as including a farmhouse” has vacillated (been tagged “both ways” 
where it is both done and not done).

The “overarching” idea I want to convey is that with good dialog “amongst 
ourselves” (I sort of duck out the “our” part:  even though were all OSM, I’m 
not from the Southern Hemisphere / around there, but we do share most of a 
language and at least some tagging habits) sensible tagging strategies do 
emerge.  This might be among a country (sorta happens, wiki emerges) among a 
particular group (motorists, hikers, mountain bikers…) or particular 
circumstances (when population levels are above or below a certain threshold, 
when an agreement arises to do a certain kind of routing using a certain method 
of tags…).  The result of “we did a lot of discussion about this” can 
frequently result in “ah, at long last we have rather wide agreement.”  Not 
always, but often enough that the investment in discussion (like this) pays 
dividends in the long run.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Country homesteads?

[stevea]

I don’t know what Oz'll end up doing, but I’ve been mapping landuse=farm, which 
became landuse=farmland, since 2009.  I’ve also used landuse=farmyard (renders 
in Carto as a “stronger tan-orange” compared to “faint orange” for farmland), 
but I initially restricted my use of farmyard to what (in US English) I think 
of as a “farmyard:”  areas used to store equipment, like irrigation-related, 
maybe a barn or roof-only that keeps a tractor dry, “tool staging,” maybe dry 
area or bins to store feed, etc.  It turns out, and I only learned in 2020 to 
tag inside of a landuse=farmland with landuse=farmyard on a polygon that 
encloses the “residential” area (not actually tagged landuse=residential, but 
it might as well be that) for the building=house, or “farm house” where the 
people who live on this “family farm” sleep at night.  Our wiki [1] told me 
this, and I myself have added a few landuse=farmyard polygons (with a farmhouse 
inside) after (recently) learning that this is well-used (and well-documented) 
tagging.

See, because landuse=residential for the farmhouse would collide with 
landuse=farmland (which renders?), doing it with farmyard-inside-farmland works 
to identify the farmhouse (area).  Try it, after seeing the photo in the wiki, 
it makes sense, and the rendering (more color saturation where the people are) 
is visually pleasing, if not more semiotically sensible.

Of course, there’s lots of other good tagging senses for “country homesteads" 
identified in this thread.  Use what works, don’t use what doesn’t.  OSM is 
nice like that, but it is good to share and discuss, especially on national 
mail-lists, where a lot of nodding and agreeing happens.  You’ve got “sheep 
stations” and such, it may very well be that Down Under develops its own 
(not-too-quirky, but uniquely Strine) methods of tagging “country homesteads.”

Happy mapping.

[1] https://wiki.osm.org/farmyard and see the photo in the “When to use…” 
section
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Mapbox mapping activity

[stevea]

Thank you (Alex) for the wide notification that DWG is aware.

I'll let DWG handle it, while I'll say out loud (I already have, I sharpen my 
meaning here and now), "that shouldn't have happened, Mapbox" (not Sergey, but 
higher up in Mapbox than Sergey).  Somebody was "asleep at the switch."  Please 
solve this, Mapbox, I believe DWG can help you do so, if DWG hasn't already.  
I've spoken with Mapbox people at your older Washington offices (upstairs from 
the "back alley," where was that, Q Street?  R Street?) years ago and you are 
still a small company; this is a people thing, not a tech thing.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Mapbox mapping activity

[stevea]

OK, I've found the links, but a couple of things:

1)  On the wiki page (about "linting," I've used "lint" in C code, is that what 
you mean?), I don't want to see "examples," (although, they are better than 
nothing), I want to see SPECIFICS.

2)  The GitHub page is also pretty vague.  You say "we use internal Mapbox data 
validation jobs that search OSM data for errors for detecting issues related to 
road network data in Australia. In total, we are going to review issues in 9 
categories."

OK, WHAT 9 categories?

I appreciate that you are "offering notice," but please be less vague.

> On Apr 22, 2022, at 12:08 AM, Sergey Beliamei via Talk-au 
>  wrote:
>> 
>> Hello from the Mapbox Team!
>> In April 2022 our team is going to start a mapping project in Australia. As 
>> part of on-going work to improve the quality of OpenStreetMap data, our team 
>> is planning to review a subset of the detections to better understand the 
>> type of issues, and also fix any valid data issues directly in the OSM. 
>> We're concentrating on road mistakes to improve map condition. In Australia
>> we plan to upload data once a week to see and fix the latest mistakes in 
>> mapping after reviewing the 1st iteration.
>> We would really appreciate your feedback, any questions you have about this
>> project, as well as local insights that you think will help us better 
>> understand the data.
>> There's a link to our Github ticket to the related issue and a link to our 
>> page in OSM Wiki.
>> 
>> 
>> Best regards,
>> Member of Mapbox team,
>> Sergey
> 


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

Re: [talk-au] Mapbox mapping activity

[stevea]

Mmmm, yeah:  I'll second Graeme's "that doesn't make much sense to me."

What does "review a subset of the detections to better understand the types of 
issues" actually mean?

And, "1st iteration"...of WHAT?

What data?

How can we give feedback on a "related issue" that is neither stated nor 
"linked to (your) Github ticket"?  Which is NOT linked here?!

Try again, please, Sergey.  That initial email of yours was a non-starter.

> On Apr 22, 2022, at 12:08 AM, Sergey Beliamei via Talk-au 
>  wrote:
> 
> Hello from the Mapbox Team!
>  In April 2022 our team is going to start a mapping project in Australia. As 
> part of on-going work to improve the quality of OpenStreetMap data, our team 
> is planning to review a subset of the detections to better understand the 
> type of issues, and also fix any valid data issues directly in the OSM. We're 
> concentrating on road mistakes to improve map condition. In Australia
> we plan to upload data once a week to see and fix the latest mistakes in 
> mapping after reviewing the 1st iteration.
>  We would really appreciate your feedback, any questions you have about this
> project, as well as local insights that you think will help us better 
> understand the data.
> There's a link to our Github ticket to the related issue and a link to our 
> page in OSM Wiki.
> 
> 
> Best regards,
> Member of Mapbox team,
> Sergey


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

Re: [talk-au] Unclassified Highway Speeds

[stevea]

I say this "from a great distance," but here goes:  if you consider that 
AU:Urban or AU:rural (and/or similar) are QUITE LOOSE compared to EXPLICIT 
tagging, you might be able to nudge things ahead in a semantic parsing sense.  
It won't be perfect, it likely never will be (ambiguities about whether it's 
valid to "do" this, or that...are never-ending) but it can "oomph things 
forward" a bit, sometimes more.  Not much more than that, but better than 
nothing.

This is tough stuff, and it is context-driven as to where there is a boundary 
and where fuzzy becomes "um, I'm shrugging my shoulders."  Keep an eye on that.

> On Apr 21, 2022, at 12:09 AM, Andrew Hughes  wrote:
> 
> Thank you all for your contributions to this thread so far, much appreciated!
> 
> Please correct me if you disagree with this...
> 1. So it would seem that ALL roads should be tagged with maxspeed and 
> assigned a numeric value (kph), where the maxspeed is known.
> 2. Supplementary to #1. the maxspeed:type tag also adds information of value 
> because it can indicate if the maxspeed is "signed" or on the basis of it 
> being unsigned and relative to its geographical ("AU:Urban" or "AU:rural") 
> location.
> 
> Important question...
> The guidelines also suggest that the use of maxspeed = "AU:Urban" or 
> "AU:rural" without a maxspeed tag could indicate that this has not been 
> surveyed. Adding this tag (with these values) without a maxspeed is also 
> encouraged as it improves the data such that the maxspeed can be assumed with 
> far greater accuracy (50pkh/60kph NT or 100kph), and loosely indicates the 
> survey status.
> 
> Cheers,
> AH



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

Re: [talk-au] Unclassified Highway Speeds

[stevea]

Very nice to see this discussion.  At this point, I believe I am some Yank who 
babbles too much.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Unclassified Highway Speeds

[stevea]

On Apr 19, 2022, at 4:29 AM, Andrew Harvey  wrote:
> ...Otherwise I think this will always be lacking in OSM until those maxspeed 
> tags are set.

Right: this is the crux of what I was getting at. Explicit data in OSM can be 
trusted, implicitly inferring data because of "defaults," well, not so much. 
(Or, it is highly ambiguous as you might attempt to do so).
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Unclassified Highway Speeds

[stevea]

On Apr 18, 2022, at 6:50 PM, Andrew Hughes  wrote:
> We're using OSM and pgrouting and it's GREAT!
> 
> Something that I have found difficult to come to terms with, is assigning a 
> "default speed" for unclassified roads (without a maxspeed tag). This is 
> because in metro area's these are most-likely to be 50kph. However, out in 
> regional areas these are likely to be 100kph.

This is an interesting “edge” that OSM seems to bump up against every now and 
then, sometimes rather public (like on a talk-list), sometimes less so, but it 
still happens.

The following is a bit fuzzy, please allow me a bit of leeway.

What I have noticed is that there are “defaults” in a legal jurisdiction for an 
activity (such as “driving through a residential zone in the state of X”) where 
that implies 40 km/hr, or 25 MPH, or some such.  What OSM seems to continue to 
struggle to do is to somehow capture this idea, whether in tagging, in wiki, in 
“understood defaults” or in some combination of the above (and/or more inputs).

While it might seem like this can be done and/or is a good idea, it can break 
down as a wider audience (of OSM downstream users / renderers / routers / use 
cases) struggles to “parse what is.”  By the latter, what I mean is that the 
combination of ambiguously “understood to apply” defaults (whether legal, in 
OSM somehow, like in a wiki, or other) become murky.  It isn’t always clear 
what to do because of what is tagged (and what might be, or isn’t, or could be) 
and understood.

Please, I urge all to be careful when we make assumptions based on “well, in 
Western Australia…” (for example) because this is a commercial zone, we can 
assume a speed limit on an unclassified road.  Sometimes it’s safe / effective 
/ realistic to assume defaults apply, much of the time it is not, and such 
assumptions are folly.  It can be difficult to even describe these, as I 
struggle for words as I type here.

So, if you’re going to do this, you have to imagine that you can imagine all 
future, downstream use-cases.  Maybe you can, maybe you can’t.  Be careful.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] admin_level, suburbs and rendering; should the order be updated?

[stevea]

I'm mighty obliged to you for that excellent synopsis; thank you.

Yes, at a certain point such "proposals" have to "be discussed amongst 
yourselves," of course, I've seen this and you are in a "certain stage" of such 
things.  Then there is your primer on "Aussie 2, 4, 6," excellent.  Yeh, the 
odd numbers can be odd ducks.  Odd you haven't any 8s.  OK, I'll keep my mouth 
shut after that.  Watching from a distance (quite a distance, from California) 
and waving g'day, mate.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] admin_level, suburbs and rendering; should the order be updated?

[stevea]

See, what I'm getting at is saying ACT District is 5, yet 7 means District, 
well, that ambiguity trips me up.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] admin_level, suburbs and rendering; should the order be updated?

[stevea]

On Apr 10, 2022, at 5:53 PM, Dian Ågesson  wrote:
> Thanks Andrew,
> 
> I'll make the adjustments to level 7 and 9 in the update guidelines as I 
> prepare them.
> 
> I can also add the Districts of the ACT in at Level 5 as well, although 
> should it be documented for all states' counties? 
> https://en.wikipedia.org/wiki/Lands_administrative_divisions_of_New_South_Wales
> 
> https://en.wikipedia.org/wiki/Cadastral_divisions_of_Victoria

Thank you Dian.

I'm not sure which "update guidelines" you are preparing, I'd love to see a 
link to our wiki about these data, if that's what you mean (and when they are 
ready, beyond your preparation and shared with the world, of course!)

You mention both administrative divisions and cadastral divisions.  The former 
enter OSM while the latter do not.  Well, that's my understanding.  It may be 
that ini Australia these do blur and it is simply "understood" that there are 
"matches" between admin and cadastral "levels" of boundaries, so admin_level 5, 
7 and 9 are appropriate for "certain things."  If I'm being noob-ish and 
blurring what "everybody already knows," please excuse me, I'm not from around 
there.  Maybe one way to say it is "called cadastral because of history, now de 
facto and de jure administrative."  I really don't know.

I do want to make sure I'm looking at the right row in the table [1] about what 
these numbers mean (or maybe look elsewhere...in our wiki?  something 
AU-specific?):

For 5, I don't (our wiki doesn't) see anything specific noted
For 7, I see "District or Region Border (e.g Perthshire, Fitzroy, Canning, 
Greater Sydney, Greater Melbourne, etc.)" and
For 9, I see "Locality Border (Suburbs or Towns) (ONLY where larger than ABS 
boundary)"

Am I ship-shape here?  Where might I discover ACT Districts are admin_level=5?  
Is there a wiki?  Thanks.

[1] 
https://wiki.osm.org/wiki/Tag:boundary%3Dadministrative#10_admin_level_values_for_specific_countries
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] admin_level, suburbs and rendering; should the order be updated?

[stevea]

Speaking from personal experience as only one participant over many years 
(between say, 2012 with some agreement in 2015 and some refinement 2020) in a 
big country with a lot of states and dozens of their idiosyncrasies, getting 
admin_level values "right" can be a true, multi-year-long wrangle to get these 
"more or less correct by wide agreement" in any given country. Keep up the 
dialog, it can only get better.

Although, there are circumstances where it simply breaks down (in the USA, 
there is a "concurrent sovereignty" with aboriginal boundaries that isn't 
really mathematically / geographically / geometrically accurately capture-able 
with admin_level, so it isn't perfect and likely never will be). A "do our 
best" approach (in any given country, admin_level=2, down to the 4, 5, 6, 7, 8, 
9 and 10 levels) often has to go right down to the "here's what we do here, at 
this relatively-medium-low-level, and that's how it is" and OSM does its best 
to accurately fit that into the country-wide scheme (via wide agreement among 
that country's region's mappers). Tables with state-by-state entries can help, 
expect lots of footnotes as in [1], although, [2] is a "novice-friendlier" 
version. There are places where OSM agrees with and mimics what our USA Census 
Bureau does, there are places where it doesn't, though the reasons OSM does 
that (and where) are explained clearly in our wiki. That helps, too.

Local knowledge is good here. Wide agreement is good here. Some edges where 
minor disagreement happens is likely inevitable, but I think Australia can 
"largely get this correct" even down to the neighborhood level (10). It takes 
years, it takes a great deal of dialog. It can be hard to say "how done it is."

[1] www.osm.org/wiki/United_States_admin_level
[2] www.osm.org/wiki/United_States/Boundaries
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] JOSM multipolygon how-to?

[stevea]

To be sure everyone reading knows, JOSM's buffer has amazing undo capacity, I 
believe "all the way back to the beginning of the session."  And there's the 
fact you can edit, edit, play with things all day and night long, then you 
simply do not upload to the OSM servers (and into the fabric of our map).  
That's a delightfully clear boundary and when you decide you DO want to upload 
your changes, JOSM wraps doing that up quite nicely (with the way it prompts 
for changeset comments, et cetera).

Good editor, JOSM.  I can't like it enough!  (Meaning I'm crazy-enthusiastic 
for it).

OSM data structures nutshell:  there are nodes, ways, closed ways (polygons) 
and relations.  Relations can be routes, boundaries, multipolygons, 
special_econonmic_zones, aboriginal_lands...these values are around 18 and they 
are all slightly different, with different rules about what's on the role tags 
and similar but pretty simple stuff.  Keep all that straight (it does take 
practice) and you've technically mastered writing data into OSM (at a volunteer 
Contributor level).  There's more to mastering OSM than that, but such 
technical mastery is a great start and even a pretty tall perch from which to 
further survey the OSM landscape.  It's a bit like "I can fly."

Have fun mapping, everybody.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] JOSM multipolygon how-to?

[stevea]

On Apr 7, 2022, at 10:36 PM, Andrew Harvey  wrote:
> It means JOSM hasn't downloaded all the member ways, in one of the panels on 
> the right showing the relation, right clicking download incomplete members 
> will fetch them all.

Yes, Graeme, if you see in the bottom left pane of JOSM's relation editing 
window "incomplete" as some of the members of the relation, you should click 
one of the two bottommost buttons along the left edge of this window:  either 
"download all incomplete members" or "only download the selected ones" (in the 
left-half of the bottom of the window).  The icons should make clear which is 
which (or will with practice).

If you aren't going to "work with" (edit) or upload that relation, this isn't 
strictly required, but only seeing / having in your JOSM edit buffer some of 
the pieces of a relation (of any type) can cause some rather undefined 
behavior.  It takes practice to see this and know what to do with situations 
like this, but you get the hang of it after working with relations whether you 
do or don't need to download any additional members.  Basically, if you are 
editing that relation, absolutely, you should download all members.  If you are 
simply taking a look, not so much.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Tagging bicycle on footpath laws Was: Re: HighRouleur edits

[stevea]

On Apr 7, 2022, at 10:31 PM, Andrew Harvey  wrote:
> Well your router would need to look up the specific default whether that's 
> something in the routing engine configuration, pulled from the OSM wiki, or 
> pulled from the Victoria state relation def:* tags.

Right, I agree:  that's part of the "hm, what is really being 'meant' in this 
(regional) context?" question that happens at the downstream use case of "this 
set of tags on this way / this relation context..." means THIS.


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

Re: [talk-au] Tagging bicycle on footpath laws Was: Re: HighRouleur edits

[stevea]

On Apr 7, 2022, at 9:53 PM, Graeme Fitzpatrick  wrote:
> I think this is getting too much into mapping regulations, we could just have 
> no bicycle tag and leave it to data consumers to apply the regional defaults. 
> 
> What would that do to bike routing?

There is bicycle infrastructure tagging (like cycleway=lane and even 
bicycle=yes) on a way (sometimes on a node, like amenity=bicycle_parking) and 
there is bicycle route tagging (like type=route, route=bicycle, network=rcn) on 
a relation.

These are related (the former should be elements properly tagged in the latter, 
but if not, it isn't strictly wrong in some cases), but they are independent.

I think what Andrew H. means by "regional defaults" is to allow the "laws in 
reality on the ground at the time of the data consumer consuming" combined with 
whatever tags there are in OSM to "rule," and "proceed accordingly."

Yes, it is nice when everything is tidily tagged as it truly exists in reality 
and these infrastructure elements are "properly" tied together into a cohesive 
networks in a local, regional, national and international scheme, rendering in 
renderers that pay attention to this tagging and display appropriately.  (And 
additional tags like cycle_network=* even go further to acknowledge what the 
specific network actually IS at a given level, too).  OSM's data isn't like 
this all over Earth, but there are places (Europe, USA, some countries in Asia, 
Australia is getting better...) where it is more and more complete.  Especially 
the complexities of international bicycle networks like EuroVelo at the 
network=icn level, combined with a rich mountain biking network (route=mtb, not 
route=bicycle, especially in the Alps and Germany, Switzerland and BeNeLux 
countries), Europe really shines here.  But it does kind of fall down with 
implementation of cycle_network=*, but even that gets better (slowly), where 
the USA and other countries have "OK or even decent" tagging.  Even more 
complex bicycle (route, especially) tagging has recently been proposed and is 
both underway and being restructured in newer tagging Proposals.

So it depends on what you mean by "bike routing."  Bike infrastructure tagging: 
 that's what's being discussed, and it seems to be a fuzzy-one-way-vs.-another 
legal cleaving based on how laws get interpreted.  A "solution" like what 
Andrew H. suggests can "kick the can down the road," though actually the 
approach of "let the data consumer make assumptions about this or that given 
being a particular region" isn't wholly wrong, either.  There is an "effort 
expended (invested) equals value derived" equation to be understood here.  
Then, hit the sweet spot.  Repeat, and pretty soon we're all winners with the 
data being a small investment (in correctness, because Oz agrees "this is how 
we do it here") and the value gained being "hey, bicycle routing around here 
makes a lot of sense!"  It can be done.

There's plenty of complexity here, but it can be teased apart, especially when 
there are pockets of both better and not-so-good tagging in a big country like 
you've got there, and you can say "this method is more complete, effecting an 
emergence on how we want to do this in Australia in a manner that is well on 
the way to being fully 'done' here."  That way, a comparison "towards the 
better" (method of tagging that has already become established in that "neck of 
the woods") can show where there are deficiencies in tagging that need some 
boosting-to-better.  Make a sub-project out of "bettering the deficiencies" and 
boom, biking is better.

This works for anything in OSM, really.

For footpaths and bicycles on footpath law, there's lots of how the rest of the 
world does this.  Take a look at our wiki, fashion existing tags to work for Oz 
(or rework them so they do, if required) and agree amongst yourself.  I know 
I'm both telling people what they already know and that it isn't always easy or 
non-messy to "agree amongst yourselves," but that's OSM.  You gotta roll up 
your sleeves, talk to each other, agree, and tag accordingly.  Not necessarily 
in that order.

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

Re: [talk-au] Map Note Flood

[stevea]

In the spirit of the OSM tenet of "be bold," and because you (all) have been so 
open about the real vandalism / destruction this one person (account) is doing 
to our map, I say "go ahead and revert his changesets yourself."

I've done this before when "the clear and present danger" of vandalism is 
taking place, and I'm not the DWG, "simply" a conscientious OSM Contributor who 
cares about data quality.  It is bold, yes, but it is allowed, and it is not 
unheard of (i.e. it is "heard of").  I suffered no consequences for doing this, 
in fact a couple of times I was (individually) thanked by the wider community 
when certain persons figured out I'd cleaned up a mess or two.

Yes, it's good that you've knocked on DWG's door, they can be busy.  If you 
can, "share the load" a bit and scrub away the stains yourself:  you really are 
allowed to do this, given all the steps you've already taken (to no avail).

If you don't know how to do this, please contact me off-list.

> On Apr 3, 2022, at 8:28 PM, Phil Wyatt  wrote:
> 
> Another 60 changesets this morning!
>  
> Is there any other way to alert the Data working group? I suspect there will 
> be over 400 changesets to revert and they will get harder the longer he adds 
> data.
>  
> Cheers
>  
> From: Phil Wyatt  
> Sent: Monday, 4 April 2022 10:29 AM
> To: 'Graeme Fitzpatrick' ; 'Andrew Davidson' 
> ; 'OSM - Andrew Harvey' 
> Cc: 'OpenStreetMap' 
> Subject: Re: [talk-au] Map Note Flood
>  
> Hi Folks,
>  
> Can someone else please log a request to the Data Working Group re this user. 
> I suspect me email is not getting to them as I have not even received an 
> acknowledgement as yet (which I gather should be instantaneous)
>  
> He is still working away adding road names
>  
> Changesets in Australia by PopeyePopcord
>  
> d...@openstreetmap.org
>  
> suggested reverts
>  
>  
> 119223580
> 119223590
> 119223592
> 119223605
> 119223620
> 119223637
> 119223650
> 119223659
> 119223666
> 119223674
> 119223683
> 119223719
> 119223741
> 119223758
> 119223766
> 119223781
> 119223790
> 119223806
> 119223819
> 119224021
> 119224028
> 119224065
> 119224109
> 119224938 - maybe dont revert this - SWAVU comment
> 119225009
> 119225018
> 119244811
> 119244940
> 119247805
> 119247832
> 119247850
> 119247892
> 119247910
> 119247919
> 119247973
> 119248033
> 119248057
> 119248118
> 119248169
> 119248239
> 119248274
> 119248322
> 119248753
> 119248767
> 119248789
> 119248810
> 119248822
> 119248862
> 119248914
> 119248959
> 119249026
> 119249073
> 119249093
> 119249135
> 119249266
> 119250024
> 119276663
> 119276678
> 119276773
> 119276793
> 119276824
> 119276841
> 119276875
> 119276933
> 119276992
> 119277068
> 119277105
> 119277136
> 119277169
> 119277230
> 119277248
> 119277257
> 119277364
> 119277377
> 119277756
> 119277793
> 119277821
> 119277902
> 119277945
> 119277971
> 119278013
> 119278024
> 119278060
> 119278075
> 119278139
> 119278155
> 119278198
> 119278239
> 119278334
> 119278421
> 119278439
> 119278464
>  
>  
> Cheers - Phil
>  
>  
>  
> From: Phil Wyatt  
> Sent: Sunday, 3 April 2022 12:32 PM
> To: 'Graeme Fitzpatrick' ; 'Andrew Davidson' 
> ; 'OSM - Andrew Harvey' 
> Cc: 'OpenStreetMap' 
> Subject: Re: [talk-au] Map Note Flood
>  
> Hi Folks,
>  
> He is back at it in Australia, mainly in aboriginal communities – adding 
> street names and population and still no response for any changeset comments.
>  
> I am collecting all the changeset numbers but no response from the data 
> working group as yet
>  
> Cheers - Phil
>  
> From: Graeme Fitzpatrick  
> Sent: Saturday, 2 April 2022 4:52 PM
> To: Andrew Davidson ; OSM - Andrew Harvey 
> 
> Cc: OpenStreetMap 
> Subject: Re: [talk-au] Map Note Flood
>  
> Looks like we have somebody playing games?
>  
> https://www.openstreetmap.org/note/3111672#map=15/-12.5048/135.8049
>  
> https://www.openstreetmap.org/user/PopeyePopcord
>  
> https://www.openstreetmap.org/user/PopeyePopcord/history#map=6/-18.272/136.714
>  
> AndrewH - you may need to swap to DWG hat for a moment?
>  
> Thanks
>  
> Graeme
>  
>  
> On Thu, 31 Mar 2022 at 15:39, Graeme Fitzpatrick  
> wrote:
>> Just had a comment made by somebody in the US on one of the Notes I worked 
>> on: https://www.openstreetmap.org/note/3111658
>>  
>> Apparently copying from HERE.com
>>  
>> They have referred to DWG.
>>  
>> Thanks
>>  
>> Graeme
>>  
>>  
>> On Thu, 31 Mar 2022 at 11:50, Andrew Davidson  wrote:
>>> > On looking at the notes added in Australia, they do seem to be an 
>>> > automated script comparing what’s in OSM to an external source.
>>> >
>>> > The notes added to Nhulunbuy, Groote Eylandt and Maningrida don’t seem to 
>>> > be coming from a suitable NT give source. One of the notes suggests a 
>>> > street name for a road I was only able to find in Google Maps.
>>> >
>>> 
>>> That's the weird bit. They seem to be a mix of stuff from Google Maps
>>> and completely fictional stuff. Maningrida as far as I can tell
>>> doesn't have street names.

Re: [talk-au] Help with bikeways on roads please

[stevea]

Yes, as someone very involved with bicycle routing (and infrastructure), thank 
you for noting the distinction that bicycle infrastructure tagging is ONE thing 
(and important) and bicycle route tagging (inclusion of usually the latter 
elements in a route relation) is ANOTHER (important) thing. These are quite 
distinct and you CAN have one without the other, although it is much more 
common for infrastructure tagging to exist, but that way element is not 
included in a route relation rather than the converse.

OpenCycleMap (OCM) does indeed display bicycle infrastructure tagging (e.g. 
"blue casing" on cycleway=lane), AND it displays bicycle routing in a way that 
has become familiar to many users (dark blue = route part of a local cycleway 
network, purple = regional, red = national), but OCM does not, for example 
display international cycleway network routes. So, also "thank you" for 
mentioning that cyclosm (.org) is an "emerging" alternative (as it is current 
in a version beginning with 0 zero) which renders BOTH infrastructure tagging 
AND route tagging in a way that happens to be richer than OCM. Sometimes, OCM 
is exactly what you want, sometimes not. Sometimes, cyclosm can "better 
display" what you are looking for.

But the important thing is: tag infrastructure where it exists, tag routes 
where they exist. Then, you can choose the renderer that appeals to your 
end-use as you best see fit.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] OSM Notes

[stevea]

On Mar 7, 2022, at 12:41 AM, David Wales  wrote:
> ...I took the opportunity to belatedly add this.

It’s like a good story with a wonderful happy ending.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] OSM Notes

[stevea]

On Mar 2, 2022, at 1:18 AM, Graeme Fitzpatrick  wrote:
> Have they simply forgotten that they posted them, so a reminder would og 
> their memory; or as suggested, do they want somebody else to do the actual 
> mapping work for them?

Let's not forget that a Note is often added by a "lesser experienced" mapper 
(or maybe not even a mapper at all, I think there might be methods for 
non-Contributors to add a Note, like through certain apps...please correct me 
if I'm wrong).  They add a Note because it is "better than leaving a noticed 
error," but they can't (or won't) fix it themselves.  So, YES, they DO want 
somebody else to do the actual mapping work for them.  There is nothing wrong 
with this, it is part of why Notes exist, so let's incorporate that knowledge 
into why somebody posted a Note in the first place:  it isn't so we can grumble 
at their "laziness," it is to "request an assist" by a mapper who comes along 
later and says "yup, there's a problem here, I know how to fix it, and they 
whack away the error into mapping data bliss."  (Right there, for that issue).  
And, "another one (Note) bites the dust."

As we Resolve a Note, it's a full round-trip on what is supposed to happen with 
them.  Even one at a time this is true, but especially when you get 
national-scope efforts to fix these (thousands at a time), the quality of our 
map data just goes up, up, up.  I smile at the thought of it:  such feedback 
loops are wonderful.

Congrats on the Weekly Newsletter horn-toot!
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Assistance with ongoing disagreement regarding intersections

[stevea]

This might be tangential to the discussion, on the other hand, it might be a 
kind of "hidden" or unstated assumption about how ways are "interpreted" in OSM 
to mean some implied given semantic, which in my opinion, they shouldn't do.  
So it could be revealing.  Here goes:  any given way should be explicit as to 
what it is doing there by virtue of two things, its tags and its relation 
memberships (if any).  A third might be "connectivity," that is, whether a 
terminal node of the way is shared by another way.  But, "that's it."

I think everybody can agree that there are many, many methods of OSM's data 
existing in situ (in their proper place) such that all of the variations 100% 
accurately describe the data.  For example, whether a segment of highway 
between points A and B is made up of one single way (ideal in some sense of 
"perfection") or two, or three segments of way that have been split, doesn't 
really matter to the underlying correctness of things.  Of course, we don't 
want to split that way into a needlessly large number of segments "just for 
grins."  But then, there ARE cases where splitting a way is exactly the right 
thing to do, for example so that correct segment(s) are properly accommodated 
as elements of a (route...) relation.

I don't think OSM data consumers can rely upon a given way representing whether 
a legal distinction exists simply by the way being "this way" vs. "that way" 
(because one way got split at "some particular location").  Let the tags on 
those ways or their inclusion in a relation do that, because that is reliable 
and clearly stated (by explicit tags, or explicit inclusion as members).___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] OSM Notes

[stevea]

Not boring at all; mighty impressive knock-down, actually.  Go Team Oz!

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

Re: [talk-au] train tour

[stevea]

Nice.

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

Re: [talk-au] train tour

[stevea]

On Feb 20, 2022, at 2:41 PM, Graeme Fitzpatrick  wrote:
> On Sun, 20 Feb 2022 at 18:24, Warin <61sundow...@gmail.com> wrote:
> 
> Some of ours, such as the India Pacific, are tourist only,
> 
> I thought the IP also delivered some freight / supplies to the "towns" 
> (alright - flyspecks!) across the Nullabor?
> 
> Would that change anything at all?

Sounds like railway:traffic_mode=mixed (in the infrastructure elements).  See 
https://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging .
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] train tour

[stevea]

On Feb 19, 2022, at 4:11 PM, Warin <61sundow...@gmail.com> wrote:
> Someone is mapping a 'train tour' into OSM.
> Should such things be mapped?

Yes.  As someone who extensively maps rail infrastructure relations 
(route=railway) as well as both passenger routes (route=train, 
route=light_rail, route=tram, route=monorail...) which are "typical passenger 
trains" (like commuter lines, light rail, urban trams, airport-style 
monorails...) AND passenger routes on rail which are "heritage / tourist / 
museum" trains, it is clear to many in OSM that these deserved to be mapped:  
they are quite extensively.

Additionally, sometimes the (subtle, see above!) tagging schemes (not to 
mention PTv1 and PTv2 differences) for these differing kinds of passenger rail 
services (passenger=international, passenger=national, passenger=regional, 
passenger=suburban, passenger=urban, passenger=local) need explaining.  
Sometimes, such "tourist" routes deserve to be tagged "passenger=local" (or 
maybe urban, depending on length and speed), if they provide some modicum of 
passenger service (in addition to the touristic or "heritage / museum" kinds of 
services).  Other times, a passenger=* tag doesn't belong, as the trains are 
only for excursion or educational purposes.

For a rich example, please see 
https://wiki.osm.org/wiki/California/Railroads/Passenger , especially the last 
section:  "Tourism, museum, heritage and historic (possibly passenger=local) 
trains."

Do recall that it is typical around the world for there to be TWO route 
relations associated with such a passenger route:  the underlying 
infrastructure (route=railway) and the passenger route proper (route=train / 
light_rail / tram / monorail...).  The latter have Public Transport Version 1 
and Version 2 variants.  Additionally, Germany often has a third relation (at 
the "bottom" of this hierarchy of routes) known as route=tracks, which isn't 
often found outside of Western Europe.  Australia appears to be a place where 
route=tracks relations are seldom, if ever, found.

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

Re: [talk-au] Help - Node relocation

[stevea]

Lisa, also, please know that it can take different times for the various "zoom 
levels" of the map to show the same data.  For example, zoomed way up close, 
all might look correct, then you zoom out (and it's OK), but you zoom out "one 
more level" and it's like it was yesterday, or two days ago.  The "rendering" 
of the map simply needs to "catch up," and this can take minutes, hours, days 
or even weeks (at wide zoom levels for particular items).
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Help - Node relocation

[stevea]

Yup, Lisa, what Thorsten said:  it may be that somebody else has made an edit 
"in the meantime" and you are really seeing the nodes in the map as they are 
"right now."

It may be that you are witnessing that many people can edit the same data.  
When this gets messy," it is called an "Edit Conflict" and it can take some 
specialized steps that can get technical to "back things out" and resolve both 
edits into one, single cohesive thing that all of the data should be.  That 
doesn't happen very often, but it does happen.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Help - Node relocation

[stevea]

On Feb 17, 2022, at 8:16 PM, Lisa  wrote:
> Thank you for such a quick response :)

OSM:  We aim to please!

> When I go into Edit mode the old node that needs to be removed isn't 
> displaying, but when I am not in edit mode I can see it?
> Am I using the wrong method of editing it?
> Or do I need to do something else?

It's not that you are or aren't using a "wrong" method of editing it, there are 
several (almost MANY!) methods.  At this point it is that I don't know WHICH 
"editor" you are using.  The word "editor" can be "software editor" (like iD, 
the more-or-less "default" editor built-into a web browser you get when you 
surf to www.osm.org.  Many people use iD, especially novices.  Or, "editor" it 
can mean "human editor," like you, when you edit in OSM (using a "software 
editor" of OSM).  Whew!

So, when you click the little down-arrow to the right of "Edit" at the top of 
your OSM browser page, do you select "Edit with iD (in-browser editor)"?

Or, maybe you are not on a computer / desktop / laptop (or even tablet) and 
using a web browser, you might be on a smart-phone and using an app to edit 
OSM, like Maps.Me or OsmAnd (there are lots and lots of these).  Or, you might 
even be on a smartphone, but still using a browser (in which case, you could 
use iD like that, but editing can be "crowded").

As I don't know which (software) editor you (the human editor) are using, but I 
guessed iD (and maybe I'm wrong), I'll need to know "which software editor" are 
you using, human editor named Lisa?

And we can go from there (I hope, I don't know everything about all of them!)

If you wish, we can take it "off-list" (between us, excluding 
talk-au@openstreetmap.org in our email distribution).

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

Re: [talk-au] Help - Node relocation

[stevea]

On Feb 17, 2022, at 7:51 PM, Lisa  wrote:
(a question)

Hi Lisa:  I'm assuming you are using the iD editor.  It seems you know the 
difference between the new node being correct and the old node "needing to go," 
you can click on a node and delete it like this:

Select the node with a single click,
Press and hold until a pop-right menu toggles off (usually to the right, might 
be to the left), let go of the mouse button,
Slide your finger pointer down to the bottom icon, the trash can icon, and when 
hovered over it, click.

You just deleted the node.

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