Re: [talk-au] What is the license of vicmap2osm?

[Andrew Harvey via Talk-au]

On Sun, 1 Oct 2023, at 8:25 PM, Yuchen Pei wrote:
> The repo for the vicmap importing project, vicmap2osm[1] seems to be
> missing a license, could you add one please? Thank you.

package.json declares it as under the MIT license, but I've added a dedicated 
LICENSE file now for clarity.

> I would have created an issue on the gitlab repo if I had an account
> there, but apart from the horrible recaptcha, gitlab now also requires
> credit card information to register (!).

I'm surprised to hear that, I thought it was only required if you were going to 
use CI/CD minutes. Sounds like they had to implement these measures to combat 
platform abuse.

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

Re: [talk-au] Tracks flagged as missing from government data

[Andrew Harvey via Talk-au]

On Mon, 23 Aug 2021, at 5:40 PM, Mateusz Konieczny via Talk-au wrote:
>> I've tried to get StreetComplete to ask about access but it was rejected 
>> https://github.com/streetcomplete/StreetComplete/issues/2930
> note that it was rejected because
> 1) access is at least sometimes unsigned and not clear - is it different in 
> Australia?
> Is it possible to have a simple question where someone with zero experience 
> would reliably answer?

Physical access for vehicles is usually clear because either there will be a 
locked gate at the start of the track just off the road, or there will be no 
gate.

If there is no physical barrier and no signage saying it's private, then I 
think it's fair to consider it open to the public. I'll try to post on the 
ticket my thoughts around question wording and possible answers.

> Are there also tracks open to public entry on foot/bicycle and not in other 
> vehicle?
> It also would need to be handled - or request user to leave notes for tracks 
> not fully
> open and not fully closed if that is rare

Yes this is very common, at least in my experience either,

1. It's an agricultural track on private property (eg. a farm) and so 
access=private as no mode is allowed.
2. It's a fire trail or forestry track on public land. It's almost always 
accessible by foot, and usually accessible by bicycle, and could go either way 
for motor_vehicle.

> 2) Problem of spammy quest is real (in some areas many, many, many will be 
> public)
> but there are some spammy quests already and given high usefulness it seems 
> survivable

Correct, but in other areas many will be private so I think it's worthwhile 
considering the whole OSM project.

> 3) no community was known to want explicit access tagging on all highway=track
> (from this discussion I see that it can change)
> In such case posting comment in that issue to outcome of discussion (probably 
> documentation on OSM Wiki) that explicit access tagging is desired on every
> single highway=track in entire country would defuse that argument

Sure.

> (Or maybe it could be asked on access=unknown tracks?)

I would still opt for where no access tags are set because for me as a data 
consumer in Australia of tracks, I'll need to consider them unknown.


> No promises that it would be implemented but "Australian community clearly
> agrees that explicit access tagging on all tracks is desired" would defuse
> one of blockers.

I'm happy to work on the implementation, but that's probably the easy part, 
hard part is working out a way to write the question and answers that's clear, 
and covers most cases accurately.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Tracks flagged as missing from government data

[Andrew Harvey via Talk-au]

On Sun, 22 Aug 2021, at 5:39 PM, Little Maps wrote:
> Andrew, thanks for the super fast reply, and for the overpass query which 
> I'll cut and paste from! A few thoughts…
> 
> AH: 1.98% of tracks have public vehicle access and 8.7% of tracks have no 
> public vehicle access (of all tracks). So where we know the vehicle access 
> then 18% are public and 81% are not public access.
> 
> This makes sense. To date, in Vic at least, most mapped tracks are on public 
> land or on the public road network (the opposite trend may exist in outback 
> areas). So existing mapping is strongly biased to public tracks, and access 
> tags have mostly been used to indicate restrictions.

I'm totally guilty of this too. Warin mentioned that in NSW, tracks in National 
Park are usually no access and State Forests are usually accessible. I mostly 
encounter tracks in NSW National Parks so generally I just assumed all are 
private and public are the exception. We are all biased by our own experience, 
the only sensible way forward is to encourage always setting explicit access 
tags.

> I just re-read the Aus tagging guidelines and it has a similar emphasis. It 
> explains how to add access restrictions but doesn't say that public access 
> isn't a default on tracks or that access=public is a worthwhile tag to add. 
> I'll put together some draft text to add to the page and will circulate for 
> comment in a day or two.

Sounds great. Though access=yes is the tag for public access, access=public was 
discouraged as a duplicate of access=yes.

> I have a different take, but I think you'd be happy with my ideal router. It 
> would give me 2 options: (1) use all available tracks (public + unknown) vs 
> (2) only use known public tracks. Given how few tracks have an access tag, 
> most users would default to "show me all of them", but they'd have a choice. 
> Globally, only 3.8% of tracks have an access tag: 20.7 million of 21.5 
> million tracks don't. Any app that only used known public tracks would be 
> viewed as crippled by users and would go broke. The market would force 
> developers to show all tracks, regardless of their personal intentions.

I don't think there is any perfect solution until all tracks have an access 
tag, only compromises. You could decide to route on tracks including without an 
access tag set, with a warning or just accept there will be some bad routes and 
encourage users to report or fix those in OSM.
 
> Luckily for me, the strong bias of osm mappers for mapping public rather than 
> private tracks is why routers that do assume that access is public unless 
> indicated otherwise actually work pretty well in Vic (prob not in central 
> Aus). As more and more private roads are added we can expect this convenient 
> correspondence to fall apart though. That's why I was so concerned about the 
> Challenge adding lots of private tracks without having an access tag on them, 
> as it will be the first major influx of untagged private roads to Vic.

> A question: I don't understand how the "default value" approach differs from 
> Joe's suggestion, which as I understood it, was that if access is assumed to 
> be no, then he wouldn't have to bother adding access tags (inc 
> access=unknown) when doing armchair mapping. Doesn't this have the same 
> outcome as a default position of not needing to add a tag? However, despite 
> the fact that I don't comprehend the distinction, I don't think it matters a 
> great deal.

Not sure I understand, but if the access is known then I'd encourage it to be 
set, if it's not known, then leaving the tag value empty signals that it's not 
yet mapper let's data consumers make their own decision about how to treat 
that, and prompts other mappers to complete this data.

> If there was a discussion to try to reach consensus on whether we should 
> assume that access=yes or no when there is no access tag, I would take one of 
> two positions: support access=yes or continue to make no assumption about 
> access. I wouldn't support an assumption that access=no for the reasons I've 
> described above. I think I'd probably just take the long term view and say, 
> avoid the debate and tag everything.

If you say access=yes is assumed default, then you run into the exact problem 
here, someone who knows there is a track and wants to map it, but isn't yet 
sure about the access get's scolded for making a contribution without the 
access tag. One of OSM's core strengths is that one person can make a positive 
contribution and someone else can come along and build upon their contribution. 
Like someone adding the track from remote sources so a local surveyor can 
confirm access and tag it.

I'm all for always encouraging tagging access (or the mode specific access 
tags, motor_vehicle=*, bicycle=*, foot=*) when it's known, treating it a bit 
different to other highway=* values which are generally only mapped when not 
=yes.

> By analogy, until recently the Aus community took the view 

Re: [talk-au] Tracks flagged as missing from government data

[Andrew Harvey via Talk-au]

One more minor point about my stats, this doesn't count tracks pretty much all 
of the track is inaccessible for routing because the access tags are set on a 
gate at the start of the track. I know myself and other mappers will sometimes 
forget or not bother (which I'll try to correct now) to set access on the way 
when it's already protected from routing because of the gate. So that should 
reduce the percentage of tracks without a known access set.

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

Re: [talk-au] Tracks flagged as missing from government data

[Andrew Harvey via Talk-au]

On Sun, 22 Aug 2021, at 12:08 PM, Little Maps wrote:
> Joe, when you talk about reaching consensus, I assume you mean consensus 
> among the Australian osm community, not the global osm community. Is that 
> right? The highway=track wiki states: "highway=track does not imply any 
> particular access=* value", and different countries have adopted different 
> positions on the issue, as described here (thanks for the link Andrew): 
> https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access_restrictions
> 
> In most countries that have reached consensus, the absence of an access tag 
> on tracks is implicitly taken to mean that access=yes for motorcars. This 
> includes Austria, Belarus, France, Finland, Italy, Netherlands, Spain, 
> Switzerland and the Ukraine. (Brazil, Germany, Iceland and Belgium have 
> partial/proposal variations on a yes approach). In contrast, two countries 
> went with access=no (Finland and Denmark). Many countries haven't reached 
> consensus, including Australia. Have I interpreted this correctly?

Yeah

> This message isn't meant to be part of any process for reaching a consensus 
> in Australia. That discussion needs to be approached far more deliberately 
> and inclusively. I'm trying to understand whether, to some degree, Andrew and 
> I have been talking past each other because we have different views on this 
> fundamental issue.
> 
> About 92% of tracks in Australia do not have an access tag (TagInfo 
> Australia), about 5% have access=private, 1% have yes and 1% have no. If I 
> understand things correctly (and this is the whole point of this email), this 
> means that:

Yeah 7.85% of tracks in Australia have access=*, 3.95% have motor_vehicle=*, 
5.33% have foot=*, 4.15% have bicycle=*.

However if I count access OR motor_vehicle OR motorcar then it's 11.1% of 
tracks have vehicle access set.

While we are at it, in this way 12% define pedestrian access and 11% define 
bicycle access.

Breaking this down, if I consider (based on a selection of actual values used)

public access includes the tags: designated, destination, permissive, 
customers, seasonal, public, dry_weather, yes, 4wd, 4WD
no public access includes the tags: forestry, emergency, agricultural, private, 
no, official, military, delivery, prohibited, permit, restricted

Then 1.98% of tracks have public vehicle access and 8.7% of tracks have no 
public vehicle access (of all tracks). So where we know the vehicle access then 
18% are public and 81% are not public access.

> - Strictly speaking, since no consensus has been reached in Australia, 1% of 
> tracks are known to be open to the public, 1% are known to be closed, and 
> access is considered to be unknown on 92% of mapped tracks.
> 
> - If the community accepted a default position of access=no (i.e. all tracks 
> without an access tag are implicitly assumed to be closed to public 
> vehicles), 1% of tracks are known to be open to the public, 1% are known to 
> be closed, and access is assumed to be closed on 92% of mapped tracks.
> 
> - If the community accepted a default position of access=yes (i.e. all tracks 
> without an access tag are implicitly assumed to be open to public vehicles), 
> 1% are known to be closed to the public, 1% are known to be open, and access 
> is assumed to be open on 92% of mapped tracks.
> 
> Have I got this right? If I have, then would this lead to the following 
> implications for tagging decisions?

I don't like the idea of a default at all for tracks. It'll lead to a lot of 
wrong assumptions, and then you'll have some mappers discouraging setting the 
access value at all since it's the "default". It makes it impossible for data 
consumers to know what really is yes/no and what is incomplete data. So to this 
point I say we should not promote any kind of default value and instead say a 
missing access/motor_vehicle tag is incomplete data in OSM.

In my view, data consumers should treat incomplete access/motor_vehicle tags as 
no access because I'd rather it miss out on a potentially available route then 
route down a private track, but that's a decisions for each data consumer. This 
is not the same as promoting a default value within the tagging documentation 
in OSM.

> - Under the current position of no consensus, a "maximilist" tagging approach 
> is required, and it's equally important to add access tags to all tracks, 
> whether open or closed on the ground.

Yes that's my opinion.

> - If the community accepted a default position of access=no (i.e. all tracks 
> without an access tag are implicitly assumed to be closed to public 
> vehicles), then it's most important to add access tags to all tracks that we 
> know are open on the ground (with evidence of course). It's less of a 
> priority (but still useful) to add tags on tracks where access is known to be 
> no/private/etc.
> 
> - If the community accepted a default position of access=yes, then it's most 
> important to add access tags to all the tracks 

Re: [talk-au] Tracks flagged as missing from government data

[Andrew Harvey via Talk-au]

TL;DR;
1. no access tags don't mean access=yes (public) it just means access hasn't 
been set.
2. access=unknown is probably better than access=private + 
fixme:access=actually unknown access but I don't want routers to use this for 
now

On Thu, 19 Aug 2021, at 9:58 PM, Joseph Guillaume wrote:
> I'd suggest the problem is with routers assuming that a missing access tag 
> should be interpreted as access=yes.
> 
> If a common understanding was reached that a missing access tag on a 
> highway=track is *assumed* to imply access=no until proven otherwise, then it 
> seems the problem goes away?
> 
> When armchair mapping, I don't want to have to tag access=private, 
> fixme="access to be checked" just for the router to have that behaviour.

Exactly.

Replying to both your points Ian and Joseph, put it this way, if I was driving 
and asked for directions, I'd expect the router to ignore highway=track ways 
completely (regardless of access restrictions set) unless there was no other 
way to get there except take the track.

If the only way to route there is via the track, then I'd expect the directions 
to include it even if access=private, but with a warning note. If no access or 
motor_vehicle tag was set, then I'd expect a warning that the route may be on 
private or inaccessible tracks.

Irrespective of the MapRoulette challenges, just looking at OSM today in my 
view the most sensible defaults for highway=track without any access tags set 
would be motor_vehicle=private + bicycle=yes + foot=yes but with an added note 
that it is actually unknown.

Another anecdote, sometimes I map building footprints I can see from imagery 
alone, I don't know the type of the building, or building:levels so I just tag 
it as building=yes (ie. building of known type). Sometime later somebody walks 
past with StreetComplete and it asks them what type of building it is and how 
many stories, and sets the tags. Without me first adding the generic building 
way, the other mapper never would have completed it by choosing the building 
type.

I wasn't trying to give a definitive exhaustive list of what is a highway=track 
so yes tracks can be used by people for recreation too.

I see your point Ian, you don't want to see these roads/tracks mapped unless 
they have complete access restrictions set, and I'm trying to argue that it's 
better to have them partially mapped even incompletely so that other mappers 
and surveyors can complete it later. Either without the access tag or 
access=unknown https://wiki.openstreetmap.org/wiki/Tag:access=unknown, which is 
much preferable in my opinion than setting access=private just because you 
don't know access.

It means data consumers can treat it as truly unknown and mappers can be 
prompted to survey it (this happens with StreetComplete for amenity=parking).

access=private should be reserved when you really know it's private access, if 
you're not sure best to set access=unknown and then once you know explicitly 
set access=yes (public access) or access=private (no public access) etc.

Perhaps the problem is with how some routers assume a lack of access on tracks 
mean they are public, so the issue is with those data consumers not with OSM's 
data.

> IMO, the key problem with the Aus road network in OSM (except perhaps in Qld 
> and N Aus) is not that it has too few roads, but that it has too many. We 
> already have a big problem in Victoria with heaps of “paper roads” and 
> private roads that are tagged as open and public. It’ll take years to remove 
> those we already have. I dread to think that 1000s of new ones will continue 
> to be drip fed onto the map from a Map Roulette challenge.

I made it clear through the MapRoulette instructions that these should be 
checked with another source, so "paper roads" which can't be seen on imagery 
shouldn't be added though this process.

> It may seem crude but, given the immense size of these datasets, I actually 
> view this “soft launch” as you call it, as a “TIGER import by stealth”.  
> yeah, I know it’s not a formal import but if an organised mapping team took 
> up the challenge and added 200,000 roads without including suitable access 
> tags, local mappers will be cursing this initiative for decades.

Yep which is why this feedback here is important, but critically any organised 
mapping team would need to flag there intentions before steam rolling through 
it.

> I can’t believe that you think you are erring on the side of caution by 
> omitting suggested government access data. In what way can this be a prudent 
> approach? Even if 10% are wrong, the rest are going to be helpful. Hence in 
> contrast to your approach, I suggest “we err on the side of caution and 
> include the government tag”. 
>
> So, please add as many tags as possible that indicate likely access and trust 
> the gov data for now. That’s a better default position than no data. Perhaps 
> add a note tag saying something like “access data is from Vic gov and 

Re: [talk-au] Tracks flagged as missing from government data

[Andrew Harvey via Talk-au]

On Thu, 19 Aug 2021, at 4:07 PM, Kevin Pye wrote:
> The Vicmap TR_ROAD table has a column "restrictions", in which a value '4' 
> indicates that the road is private. In the latest version of the data, which 
> was released only in the last couple of weeks, there are 158,466 roads with 
> that restriction.

Yeah I did implement that actually at 
https://gitlab.com/alantgeo/gov2osm-tracks-conflation/-/blob/master/src/vic.js#L22-28
 which sets the tag on the feature in MapRoulette.

  1: 'motor_vehicle=private', // maintenance vehicles only
  2: 'note=seasonal closure', // subject to seasonal closure
  4: 'motor_vehicle=no', // permanently closed
  5: 'motor_vehicle=private', // private access
  7: 'note=dry weather only' // dry weather only

Whether we have enough confidence enough to trust this is the question.

A track appearing in both this dataset and on imagery in my view is enough to 
map it as a highway=track. Without an access tag we are saying we aren't sure 
and it needs surveying.

If we add the access tag from Vicmap, then in my view that becomes more like an 
import and less like armchair mapping which this quest is geared towards? So we 
need to decide if we err on the side of caution, omit the tag and let on the 
ground surveys fill in those details or blindly trust Vicmap access 
restrictions.___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Tracks flagged as missing from government data

[Andrew Harvey via Talk-au]

On Wed, 18 Aug 2021, at 4:40 PM, Little Maps wrote:
> Andrew, the 1:25,000 Vic gov topo mps show tracks/driveways on private 
> properties in a different colour to those on public land and the map 
> legend clearly distinguish the two. So hopefully there is a 
> public/private field in the dataset that can be used to distinguish the 
> two. Cheers Ian

There's nothing I can see in the Vicmap Transport dataset to distinguish this, 
if you know of another dataset that would help I'm keen to have a look. I tried 
looking at the crown land data from Vicmap, and while this would certainly 
help, it misses some areas where public forestry tracks occur.

Another option would be to use existing OSM mapped features for parks and 
reserves, which could be used to prioritise those on public land, I'll touch on 
the private land tracks below...

On Wed, 18 Aug 2021, at 6:11 PM, Little Maps wrote:
> Apologies for repeated posts on this issue,

Oh no need to apologise, the more eyes on this the better.

> but a data dump of 250,000 
> ways is worth some discussion I believe…

Agreed.

> Andrew, if it is not possible 
> to separate public and private roads using tags in the Vic gov 
> database, can the Vic Tracks MapRoulette Challenge please be pulled 
> down immediately? If you scan around the state, it’s obvious that the 
> great majority of the “unmapped tracks” are on private property and not 
> on public land. Even in the forested highlands of Gippsland, there are 
> far more “unmapped tracks” on private property around the margins of 
> the forests, and in the surrounding farmlands than in the forest itself.
> 
> With no better data available, it seems reasonable to suggest that this 
> MapRoulette Challenge includes 100,000-150,000 roads/tracks/driveways 
> on private land (maybe more), with no indication of that fact to inform 
> well intentioned mappers, and no suggested tagging to indicate 
> access=private. Many of the private roads are indeed short driveways 
> that have no through connectivity, but many are longer and create 
> through ways. In private forestry plantations in W Vic for example, all 
> of the private internal roads are included in the challenge, which 
> creates a wide grid of new “public” roads. I’ve only looked at the Vic 
> challenge so far and have no feedback yet on the challenges in other 
> states. 

highway=track are documented as forestry, agricultural or fire trails, so 
shouldn't be considered as public roads by data consumers.

Tracks on private land are useful too, for deliveries, fire management and 
emergency access.

Whenever I'm out surveying I always try to set foot, bicycle and motor_vehicle 
access tags on highway=track since I don't think you can safely assume any 
particular access "defaults" apply unlike other highway classifications where 
there are reasonable access defaults.

So in my view there is no harm in mapping tracks we know exist but don't yet 
know access restrictions, in fact I think there is a lot of benefit to getting 
them in and then later mappers can follow up with setting access tags once they 
are known.

> A couple of months ago, Microsoft’s mapping team was told to cease and 
> desist after they mapped a few 1000 private roads without indicating 
> private access (they responded to that request admirably). This 
> challenge dwarfs that issue 100-fold. I’m confident that the intentions 
> were good but this implementation is fundamentally flawed. The fact 
> that the data dump and challenge were sponsored and paid for by a 
> government department with no notification or discussion from the 
> Australian mapping community until after the fact makes the issue even 
> more problematic in my mind.

I saw the discussion in brief, but my recollection was that involved tagging 
some roads as unclassified or residential where data consumers do assume by 
default they are public access.

OSM has always been someone does a bit of mapping and others build upon it, 
rarely are things mapped perfectly from the first upload, it only becomes a 
problem when some tags data consumers have assumed defaults.

From my side I do consider this a soft launch, by uploading and publishing the 
challenges on MapRoulette it provides a good medium to distribute the results 
to the mapping community to look over. So I am very open to further feedback 
here which I can use to rebuild the challenges.

So far there is no organised mapping happening to work through these challenges.

On Wed, 18 Aug 2021, at 6:25 PM, Warin wrote:
> For NSW the tracks can be compared with the DCS Base Map so as to confirm 
> there existence and possible level of highway = track/unclassified etc.

I though it was the same data as on the Base Map, but I never checked that. 
Regardless I don't hold much trust in the DCS Base Map and only use it as an 
additional data point where all else fails, so still it's a good idea to check 
on imagery. Some tracks become overgrown to the point there are now 

Re: [talk-au] Tracks flagged as missing from government data

[Andrew Harvey via Talk-au]

Thanks for the feedback,

On Mon, 16 Aug 2021, at 7:03 PM, Little Maps wrote:
> Thanks for a great series of projects Andrew. One query… is there an error in 
> the Victorian all tracks challenge? It includes nearly 250,000 tracks to be 
> reviewed and potentially added to OSM. By contrast, taginfo states that there 
> are “only” 188,000 tracks (highway=track) in OSM across all of Australia at 
> the moment. At the suggested rate of nearly 6 minutes per track, that’ll take 
> more than 6 person-years of mapping, if one were to map non-stop for 10 hours 
> every day and 7 days every week. It certainly makes the ACT challenge look 
> attractive - they have less than 100 to do. Cheers Ian

The VIC (Priority) https://maproulette.org/browse/challenges/20216 challenge is 
the better place to start for Victoria unless you're really just looking at a 
small local area you are interested in. It only has 317 tasks compared to 
249,850 for the whole VIC. It focuses on strategically important fire trails 
which are missing in OSM.

I realised I need to re-upload the VIC tasks because it doesn't auto-load them 
into JOSM.

On Tue, 17 Aug 2021, at 10:33 AM, Adam Horan wrote:
> I've done some spot checks on the VIC priority, and I see they're also 
> included in the Track VIC challenge. Although the 316 in VIC Priority will be 
> a small dent in the 249850 in Tracks VIC.

I can try to remove these, alternatively if the VIC priority ones get done, 
then I can just re-run the rest of VIC which will pick up most of the changes 
automatically.

> Many of the ones in Tracks VIC seem to be driveways (certainly in the 
> Melbourne periphery that I scanned through), is this expected?

These tracks were done by filtering down Vicmap Transport, specificly class 6 
and 7 which are defined as:

* 6 Track 2-Wheel Drive Unimproved roads which are generally only passable in 
two wheel drive vehicles during fair weather and are used predominately by 
local traffic. Also included are driveways regardless of construction.

* 7 Track 4-Wheel Drive Unimproved roads which are generally only passable with 
four wheel drive vehicles.

I missed the last part where it mentions driveways are included, I'll take 
another look to see what can be improved to filter these out.

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

[talk-au] Tracks flagged as missing from government data

[Andrew Harvey via Talk-au]

Collaborating with the National Heavy Vehicle Regulator (NHVR), I've set up 
MapRoulette challenges which identify tracks (highway=track) which appear in 
government datasets but are missing in OSM.

The code to produce these challenges and the documentation of source data and 
waivers is at https://gitlab.com/alantgeo/gov2osm-tracks-conflation/ 
.

Where the suggested track can be confirmed with another source like 
aerial/satellite imagery or street level imagery, it could be added to OSM.

If editing with JOSM, with RemoteControl enabled, the way is added into the 
editor via MapRoulette. iD doesn't support this yet so using iD requires 
re-tracing the way from imagery. Alternatively RapID may have an AI generated 
way which if matching the imagery and government data could be used.

Care must still be taken to assess the classification, if the track is still 
active, and to join to the rest of the road network.

If you're interested, please feel free to join in the challenges, broken down 
by state:

VIC (Strategically Important Fire Trails) 
https://maproulette.org/browse/challenges/20216
- attributes from the source have been included, but if unsure they don't need 
to be brought across

VIC (Vicmap all tracks) https://maproulette.org/browse/challenges/20183
- attributes from the source have been included, but if unsure they don't need 
to be brought across

ACT https://maproulette.org/browse/challenges/20137
- no attributes included, mappers can choose the road classification

NSW (NPWS) https://maproulette.org/browse/challenges/20164
- attributes from the source have been included, but if unsure they don't need 
to be brought across

NSW (Classified Fire Trails) https://maproulette.org/browse/challenges/20232
- no attributes included, mappers can choose the road classification

SA https://maproulette.org/browse/challenges/20182
- attributes from the source have been included, but if unsure they don't need 
to be brought across

WA https://maproulette.org/browse/challenges/20302
- name included, but if descriptive and unsure it can be omitted

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

Re: [talk-au] The Paradox of Postcodes (Was Re: Victorian Vicmap Address Import Proposal - Suburb and Postcode discussion)

[Andrew Harvey via Talk-au]

On Thu, 17 Jun 2021, at 6:08 PM, Adam Horan wrote:
> 
> The ABS have an interesting factsheet on postcodes and their own 'Postal 
> Area' interpretation (POA).
> https://www.abs.gov.au/websitedbs/censushome.nsf/home/factsheetspoa 
> It starts with this statement:
> *"A postcode is a four digit number used by Australia Post to assist with 
> mail delivery. Australia Post does not currently define geographic boundaries 
> for postcodes. However, a number of organisations, such as PSMA Australia 
> Limited, create geographic boundaries that aim to define the geographic 
> extent of the mail delivery area for each postcode. Defining postcodes with a 
> geographic boundary is an imprecise process, and this is demonstrated by the 
> fact that there are variations in boundaries released by different 
> organisations."*
> **
> Some postcodes cross state boundaries, one example is 3644 which covers 
> Cobram in VIC and Lalalty in NSW
> https://auspost.com.au/postcode/lalalty
> https://auspost.com.au/postcode/cobram/vic/dgee
> https://www.google.com/maps/place/VIC+3644/ 
> 
> There are also regions with no postcode, eg parts of the wilderness in West 
> Tasmania.
> 
> Some postcodes cover non-contiguous areas eg 3585 which is in two parts 
> https://www.google.com/maps/place/VIC+3585/
> 
> In VIC at least shapefiles for postcodes exist, I didn't search more broadly. 
> The VIC data is aligned to property boundaries.
> https://services.land.vic.gov.au/SpatialDatamart/dataSearchViewMetadata.html?anzlicId=ANZVI0803003521=1
>  
> and 
> https://discover.data.vic.gov.au/dataset/postcode-boundaries-polygon-vicmap-admin

This does sound like addr:postcode on each address object is the way to go and 
correctly capture the postcode of each address. We can still have postal_code's 
on admin boundaries where the the vast majority of addresses within that 
boundary have that postcode.

Stage 1 of my proposed import adds the missing postal_code tags on these 
relations https://gitlab.com/alantgeo/vicmap2osm/#stage-1-postal_code. This can 
coexist with addr:postcode.

It's a fair point that Vicmap's own postcode field shouldn't be taken as 100% 
correct, it looks like it might have been assigned based on postcode boundaries 
so might still suffer issues because of this, but where addr:postcode is not 
already mapped, most of the time the Vicmap one will be correct.

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

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Andrew Harvey via Talk-au]

On Sun, 13 Jun 2021, at 12:24 PM, Sebastian S. wrote:
> Hi Andrew,
> 
> Have you considered adding a 
> ref:{Vic map reference}={Vic map ID} 
> Tag to the imported data points?
> 
> Or do you consider a ref tag or source tag an issue for users?

I decided against a reference, see 
https://gitlab.com/alantgeo/vicmap2osm/#why-no-vicmap-id

> I am also wondering if it makes sense to add a clean up tag for all duplicate 
> points. Think tiger data import.

The import makes a big effort to remove all duplicates before import, so it 
shouldn't be adding any duplicates. There could be cases where the conflation 
hasn't picked up on an existing address being the same, so you could end up 
with duplicates this way, but from the checking I've done so far it doesn't 
look like it would happen much.

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

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Andrew Harvey via Talk-au]

On Sun, 13 Jun 2021, at 12:21 PM, Sebastian S. wrote:
> Thanks Andrew for this great proactive communication. Please keep at it.
> 
> With regards to the suburb etc tags I must say I was swayed for some time. 
> However I still feel that including the full address has more benefits for 
> the majority of users. 
> At the same time you have also provided options for checking and maintaining 
> the data. A Maproulet task that flags POI seems a good idea to me.
> 
> It is true that the postcode etc can be deduced from the boundary relations 
> but until this is done by the consumers for all POI I will support the full 
> address.

I agree, and the posts here indicate the majority of the community prefer to 
have addr:suburb on each address object in addition to the boundary. But some 
community members here who don't want to see addr:suburb on the address object, 
so I had to decide to either push ahead based on the majority support even with 
vocal opposition, or do what I'm currently proposing which is the bare minimum 
and not include these tags. I'm open to changing this if those who oppose voice 
their support of a decision based on the majority even if it disagrees with 
their view.

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

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Andrew Harvey via Talk-au]

On Tue, 8 Jun 2021, at 7:33 PM, Ewen Hill wrote:
> Andrew,
>   Thank you for both your initial work and the communication as well as the 
> listening. Can I congratulate you on the lib/toOSM.js for the capitalisation 
> and duplication processing. Very detailed
> 
> A few numpty questions after being late to the party...
>  * Is there a node id on the vicmap address and are we storing this in OSM so 
> we can match and look for missing or deleted ones later?

Good question, I've added a section to the code repo at 
https://gitlab.com/alantgeo/vicmap2osm/-/tree/master#why-no-vicmap-id, 
essentially because such an ID makes it confusing for OSM contributors, makes 
the data feel less organic to OSM, and conflation can still be done without it.

>  * Can we provide a couple of samples of the existingAddressesWithNewTagsOnly 
> export once available

Yes I'll post the full import candidates shortly, I'm still working finalising 
them at the moment.
 
>  * Could we perform some sampling of suburbs/levels. Perhaps 
>* Mallacoota (large reserves, complex islands and altered crown/public 
> land ownership)
>* Meringur or Learmouth (large farming community)
>* Fitzroy (complex inner city)

Yes, I can sample these out, I'll post them shortly.

>  * I can't see what happens on collision with a totally incorrect address. Is 
> the new node just added where you can't find a matching address. 

At the moment yes if it doesn't find an exact match then the new node will be 
imported. In the conflation I broke the state up by city block (land surrounded 
by roads) because where there are no addresses in OSM in that block we can be 
fairly certain there will be no conflicts. Where there are addresses in the 
block there is a chance that the address exists but it wasn't an exact match, I 
haven't decided what I think should happen here.

Treating all the blocks where at least one address already exists in OSM would 
be too overwhelming to review them all manually (636,532 addresses fall into 
this category compared to 1,311,095 which very likely aren't already in OSM, 
compared to 107,194 which are certainly already in OSM).

1,311,095 Vicmap addresses are in a block which has no OSM addresses
13,830 Vicmap addresses are within an OSM address polygon (which may or may not 
be the same address)
636,532 Vicmap addresses are in a block which has some OSM addresses already 
but couldn't be matched exactly
107,194 Vicmap addresses are in a block which has some OSM addresses already 
and there was an exact match found

>* Is there an exceptions file for the above that can be reviewed. Could 
> map roulette some of these?
>  * How have you gone with best practices globally?

Let me circle back to these points. I have created two sets of MapRoulette 
challenges (not publicly visible yet) but these are for the Vicmap complex name 
and building / property name, which we aren't importing automatically instead 
via MapRoulette inviting the local community if they'd like to review these.

> I am amazed by the amount of code you have developed and documented to do 
> this. The benefits of adding this import will far outweigh any minor local 
> issues. Chapeau!

From the README I wrote, Vicmap data isn't perfect, OSM data isn't perfect. 
This import isn't without issues, it aims to get it right for the vast majority 
of instances, but local mappers will still be left with some burden of 
correcting or cleaning up edge and corner cases. I'm with you that the benefits 
outweigh the issues.  

I've done on the ground surveying of addresses and shocked by how many errors I 
made.

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

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Andrew Harvey via Talk-au]

On Wed, 9 Jun 2021, at 5:36 PM, Benjamin Ceravolo wrote:
> How is address going to be 'placed' onto the map, I assume a node?
> 
> My primary question is where is the node going to be placed? 
> 
> Will it be placed in the centre of the property/parcel? If so, they will be 
> fine in denser areas but how effective will they be in rural areas, will they 
> need to be moved to near the driveway/gate manually? or is this a non-issue? 

I touch on this at 
https://gitlab.com/alantgeo/vicmap2osm/-/tree/master#where-should-addresses-exist,
 yes it will be on a node, and the location of the node is wherever Vicmap has 
it.

Where the address is already in OSM it will be left at its existing location, 
and new addresses imported can be manually moved post import by mappers if they 
like.

> In the case of a subdivision where there is common property, will the common 
> property receive its own address, as on VicPlan it shows a separate address 
> for both the common property and the units? (see example) 

As it currently stands, yes. At that specific location 1/37 and 2/37 addresses 
from vicmap were matched with existing addresses in OSM (so nothing imported), 
and a new third address of 37 would be imported.

What do you think should happen here?

I will post the candidate import files here shortly, I'm just still working to 
make sure I've covered everything I'm aware of on my side first.

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

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Andrew Harvey via Talk-au]

To sum up the contentious issue of suburb, postcode, state tags,

- Phil, Daniel and Seb would prefer the suburb and postcode on each address 
object.
- Andrew Davidson and cleary would prefer we not include suburb and postcode on 
each address object and instead require data consumers to derive this data from 
the existing boundaries, and actively discourage mappers manually adding this 
data via removing the preset in ID.

Thinking further I'd support including the full address details on each address 
object, to provide a complete address, even if duplicated by the boundary. QA 
tools could be built to validate these match the admin boundaries and it 
becomes a maintenance task to maintain these tags, but I think that's okay.

However, to avoid stalling this import on this issue (it doesn't sound like 
anyone will change their mind soon), I'll plan the minimum viable option of 
excluding addr:suburb, addr:postcode and addr:state from the import.

There's nothing stopping a further discussion of a planned automated edit to 
update address objects with suburb, postcode and state if the community changes 
their mind later on.

I'll make these changes to the import code, then once I've completed all the 
documentation and remaining issues hopefully post some import candidate files 
if anyone would like to review.

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

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Andrew Harvey via Talk-au]

On Thu, 27 May 2021, at 8:39 PM, Andrew Davidson wrote:
> On 25/5/21 4:41 pm, Daniel O'Connor wrote:
> > I'd make a polite argument there is still value in at least the suburb, 
> > possibly postcode being still provided.  When exporting data via 
> > overpass as CSV; it's not currently easy or obvious to appropriately 
> > bring in the parent attributes; even if it is for a Real Human looking 
> > at the map.
> > There's a fair number of use cases for "data in a spreadsheet 
> > friendly format" I feel.
> 
> You don't need to add addr:suburb to get that, all you need is a little 
> Python.

I think the point Daniel is making is that's too much for unsophisticated data 
consumers, and if we can do some processing on the OSM side to make it easier 
then we should.

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

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Andrew Harvey via Talk-au]

On Tue, 25 May 2021, at 4:41 PM, Daniel O'Connor wrote:
> I'd make a polite argument there is still value in at least the suburb, 
> possibly postcode being still provided.  When exporting data via overpass as 
> CSV; it's not currently easy or obvious to appropriately bring in the parent 
> attributes; even if it is for a Real Human looking at the map.
> There's a fair number of use cases for "data in a spreadsheet friendly 
> format" I feel.
> 
> Yes, it does come with a maintenance problem when suburbs change or postcodes 
> merge, but I feel that's one problem for one set of folks - us maintainers - 
> vs a repeated problem for many simple data consumers.
> Ideally, as maintainers, we would over time semi automated this with tooling 
> (much like the proposed import)

Okay, so it sounds like we have a few people advocating including the full 
address tags even when they could be derived from a parent boundary object 
mostly because it makes it easier for some data consumers, and a few people 
advocating to not include them, and go so far as to actively discourage mappers 
adding these tags (via removing iD presets).

If we decide to include these tags, then if a suburb boundary changed in JOSM 
you can

1. Select the new boundary
2. Selection | All inside
3. Search with `"addr:suburb"='old suburb name'` using "find in selection"
4. Update all the addr:suburb tags from old to new within the new boundary

Yes it's a semi-automated mass change, so care must be taken and the community 
should be onboard with the mass change, but apart from that it's not too much 
effort.

`addr:state` won't change so there's no real maintenance burden.

Personally I feel if we won't actively delete addr:suburb tags someone manually 
adds then, we may as well add them for completeness, but not too fussed either 
way.

At this point I'm not sure of the way forward, but given I've only heard 
positive feedback for doing an import of addresses, I don't want to let this 
stop the import happening. So we'll have to pick one approach and live with it 
for the time being (can be re-evaluated later).

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

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Andrew Harvey via Talk-au]

21, at 2:05 PM, Graeme Fitzpatrick wrote:
> On this, I'm not sure if this may be an OSMAND problem, or an issue with the 
> way the info has been loaded in OSM, but here's something that I noticed a 
> few weeks ago, that may apply here?
> 
> Had to go visit a bloke for the first time, & his address is Watson Road, 
> Armstrong Creek:
> 
> https://www.openstreetmap.org/search?query=Watson%20Road%2C%20Armstrong%20Creek#map=17/-27.23885/152.81791
> 
> As you can see, Nominatim shows "Watson Road, Armstrong Creek, Kobble Creek, 
> Moreton Bay Regional Council", but when you look at Watson Road, all it says 
> is highway=tertiary + name=Watson Road, with no suburb / city, State or 
> postcode listed.

Nominatim shows at 
https://nominatim.openstreetmap.org/ui/details.html?osmtype=W=28276516=highway
 it's matching both admin boundaries, which is fair because the road separates 
the two boundaries. So addresses on one side of the street will be in one 
locality, and addresses on the other side, the other locality. Because you're 
just searching for the road and not a street number it returns both localities.

> In this area, Watson Road is the boundary between Armstrong Creek & Kobble 
> Creek "localities"
> 
> AC: https://www.openstreetmap.org/relation/11675264#map=13/-27.2282/152.7932
> 
> KC: https://www.openstreetmap.org/relation/11675296#map=13/-27.2679/152.8018
> 
> KC has also been created as a "village" 
> https://www.openstreetmap.org/node/310513460, although there is no village as 
> such, it's just an area name.
> 
> When I search via OSMAND though, it will find Watson Road, Kobble Creek, but 
> won't find Watson Road, Armstrong Creek? It will also find Kobble as a 
> suburb, & Kobbe Creek as a village, but won't find Armstrong Creek?
> 
> So, is this a peculiarity of the way the PSMA ADmn Boundaries have been 
> created, or something in OSMAND?

Maybe OSMAnd, I tried to search in the app but it was finding other results 
closer to me and not the ones you've listed here. If the address number was in 
OSM then it would probably start working as expected.

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

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Andrew Harvey via Talk-au]

On Fri, 21 May 2021, at 4:48 PM, Graeme Fitzpatrick wrote:
> With regard to postcodes how does it work when there are 2 postcodes out of 
> the same mail centre?
> 
> EG Gold Coast Mail Centre at Bundall is postcode 4217, but the GC City 
> Council, which is in that area, has its own postcode 9726?
> 
> I'll assume that this isn't limited to GC, so would that cause any issues?

I think from the analysis I just posted, it's not an issue in Victoria, except 
for 3000 and 3004 which are different parts of the same suburb.

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