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

[Ewen Hill]

Hi all,
  A fantastic thread and I feel it is important to assist those protecting
the environment over ground truth mapping.

 On lord Howe Island, currently over 70% of the island is off-limits for an
outbreak of Myrtle Rust with the Island Board stating "The rust has the
potential to change the way our mountains and forest looks, it may alter
food webs and ecology, and potentially affect world heritage values,". In
Western Australia, there is Phytophthora (dieback), now prevalent in the
Stirling Ranges which is mainly carried long distances by human activity.
In these and other more local instances,we should endeavour to assist
protection.

I feel the  lifecycle prefixes and access=no in most instances however it
might be better to remove all highway tagging other than a note to protect
fragile ecology so that no downstream map accidentally maps these.

Ewen

On Tue, 3 Oct 2023 at 23:33, Mark Pulley  wrote:

> A brief summary of the options for this type of situation (not just this
> particular edit, but similar edits in the past and probably future):
>
> 1. Revert the change sets (in the absence of more information)
> 2. Partial revert, with a change in tags
> 3. Leave the deletion as it is.
>
> For this particular example, the results would be:
> 1. Full revert - way will be marked informal=yes, but without access tags
> 2. Partial revert - could add access=no, or
> alternatively abandoned:highway=* or disused:highway=*
> 3. No reversion
>
> So far I count 5 people in favour of reversion, and 2 or 3 against (I
> wasn’t sure about the third!)
>
> Here’s my proposal:
> Partial revert of ways
> Way 29415025 - leave this deleted (as it was difficult to find at my
> survey in early 2022)
> Way 1052666246 - access to an informal lookout - leave this deleted
> Other two ways 29415022 and 630040313 reverted with addition of access=no
> (as NWPS don’t want people going there), and probably a note=* tag to
> describe the reason for the access tag
> (Possibly disused:highway=* as an alternative - this will prevent it
> appearing on the map. Unfortunately we don’t have a new survey of this
> area. The NPWS ranger doesn’t appear to want this showing on the map, but
> hasn’t given any indication on the actual status of the path. Is it
> officially closed? Other paths that have been closed in other locations
> have previously been marked access=no e.g.
> https://www.openstreetmap.org/way/347707596/ )
> Delete the viewpoint tags on the ways
> Outline in the changes comments the reason for the reversion (i.e. the
> mailing list discussion).
>
> It would be nice to have a resurvey, but I wasn’t planning to go back to
> this location any time soon to do one.
>
> Mark P.
>
> On 2 Oct 2023, at 2:12 pm, Ben Ritter  wrote:
>
> (I'm a little late to this thread, but wanted to add my two cents.) I
> agree with Tom's take and have commented below:
>
> On Mon, 25 Sept 2023, 8:26 am Tom Brennan,  wrote:
>
>> Tricky one.
>>
>> I have sympathy for Land Managers. There can be many reasons why they
>> don't want people visiting a place, and why they don't want tracks on a
>> map which might encourage it.
>>
>> But simply deleting the tracks from OSM is not the best way to go about
>> it unless the "tracks" were simply bushbashing routes, and were never
>> real tracks in the first place.
>>
>> As others have said, it just makes it likely that the track will be
>> added as a new track at a later date, assuming it does exist on the
>> ground.
>>
>> Some basic signage at the trackhead, and formal closure (announcement on
>> the NPWS alerts page) would be enough to set the various tags so that it
>> shouldn't appear on downstream maps.
>>
>
> I agree with all of this. If the track exists on the ground, something
> should exist in OSM.
>
> This situation is not a novel one that requires a new tag prefix, I think
> it should be represented with:
>
>- highway=* because it is clearly a track to a surveyor
>- informal=yes because it is not maintained like the other paths
>- access=no because the relevant authority says so
>
> It sounds like the access=no tag is less clearly justified, but any
> signage at the site is justification enough, even if it is poorly
> maintained or vandalised: the access tag is describing policy, not
> practical use. I would encourage the managers to ensure signage is
> maintained, because many people won't be using OSM as their source of truth!
>
> I think the OSM edits and email discussions also serve as justification
> for the access=no tag. A publicly posted notice would be ideal, so that it
> can be referenced as a source.
>
> If there are downstream maps that are not representing the access
> restriction, then we should put pressure on them to make use of the access
> tag. It is a very established tag, and it is the correct solution for many
> sensitive situations like this, including private property, etc.
>
> Finally, it would be somewhat helpful to mention in the description=* tag
> that use of 

Re: [talk-au] How to efficiently improve AU address coverage?

[Yuchen Pei]

On Sat 2023-10-07 20:40:47 +1100, Yuchen Pei wrote:


> [... 26 lines elided]

> mr2osc.mjs is used in Stage 2 (replacing street_number=x/y with
> unit_number=x && street_number=y). For example, the Makefile rule
> dist/unitFromNumber.osc is generated using this script. I have generated
> the osc file[1]. However, this file contains 38k nodes, whereas the
> input MR file[2] only has 12k features. So my question is - does anyonw
> know what is the easiest way to see all the changes in this file staged
> on a map, as a sanity check? OTOH I'd assume the file format is some
> standard osm change format.

On a second thought, why don't we just generate the osc file with

make dist/unitFromnumber.osc

and apply the osc file manually? Of course that's assuming the file is
correct. For example, to understand the discrepancy in the number of
nodes I mentioned above. I also noticed some minor issues with the
script, like when the number of changes exceeds 10k, it attempts to
split them multiple files, but they are identical rather than sequential
parts.

> [... 17 lines elided]

Best,
Yuchen

--
Timezone: UTC+11
PGP Key: 47F9 D050 1E11 8879 9040  4941 2126 7E93 EF86 DFD0
  

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

Re: [talk-au] How to efficiently improve AU address coverage?

[Yuchen Pei]

On Tue 2023-10-03 19:51:13 +1100, Warin wrote:

> [... 14 lines elided]

> OK, what is needed to be done for "Stage 2 - Set unit from
> housenumber"?

> Further testing of the upload script. The changes themselves are
> pretty safe. It's using a custom uploader and if something isn't
> right it could make a mess. Sure the changeset could be reverted
> in the worst case scenario but you end up with more history so
> best to avoid this. I'll see if I can find some time to progress
> this further.

> Umm 'custom uploader' .. a file compatible with JOSM should be easy
> enough to create. Then selecting a small area to upload and test would
> be a simple manual operation, as would uploading the entire change
> set.

I notice two scripts in the repo with the ability to upload:

./bin/mr2osc.mjs - converts a MapRoulette geojson to ocs files, and
upload unless --dryrun is specified

./bin/upload.sh - upload osmChange files using a python script. I have
not looked much into this one yet, as it showcases Stage 3.

mr2osc.mjs is used in Stage 2 (replacing street_number=x/y with
unit_number=x && street_number=y). For example, the Makefile rule
dist/unitFromNumber.osc is generated using this script. I have generated
the osc file[1]. However, this file contains 38k nodes, whereas the
input MR file[2] only has 12k features. So my question is - does anyonw
know what is the easiest way to see all the changes in this file staged
on a map, as a sanity check? OTOH I'd assume the file format is some
standard osm change format.

To Andrew: what specifically are you worried about with the upload
script, and how can we help with the testing and uploading?

[1] https://ypei.org/assets/tmp/unitFromNumber-1.osc
[2] https://ypei.org/assets/tmp/mr_explodeUnitFromNumber.geojson

> [... 5 lines elided]


Best,
Yuchen

--
Timezone: UTC+11
PGP Key: 47F9 D050 1E11 8879 9040  4941 2126 7E93 EF86 DFD0
  

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

Re: [talk-au] VIC addresses import (was Re: How to efficiently improve AU address coverage?)

[Yuchen Pei]

On Sat 2023-10-07 12:59:01 +1100, Yuchen Pei wrote:

> [... 13 lines elided]

>> OK, what is needed to be done for "Stage 2 - Set unit from
>> housenumber"?

>> Further testing of the upload script. The changes themselves are
>> pretty safe. It's using a custom uploader and if something isn't right
>> it could make a mess. Sure the changeset could be reverted in the
>> worst case scenario but you end up with more history so best to avoid
>> this. I'll see if I can find some time to progress this further.

> OK. Is there a way to download artefacts built on gitlab CI (e.g. a
> webpage that shows links to all the artefacts)? I'd like to compare
> files there with mine. As I mentioned elsewhere in this thread, for
> Stage 2 I could only get 212 features in the
> dist/conflate/mr_explodeUnitFromNumber.geojson I built locally.

I cleaned up the Makefile a bit[1], so that I can run `make
dist/conflate' without worrying about missing dependencies.

Running this command directly now I get 12011 features in
dist/conflate/mr_explodeUnitFromNumber.geojson.

[1] 
https://g.ypei.me/vicmap2osm.git/commit/?id=e4c6750db2fdbf80222a30cf9171461c317cd676

> [... 6 lines elided]

Best,
Yuchen

--
Timezone: UTC+11
PGP Key: 47F9 D050 1E11 8879 9040  4941 2126 7E93 EF86 DFD0
  

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

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

[Mateusz Konieczny via talk]

6 paź 2023, 13:57 od tr...@gmx.de:

> On 23-10-06 13:41, Tom Hughes wrote:
>
>> On 06/10/2023 12:12, Martin Trautmann wrote:
>>
>>> On 23-10-06 12:55, Tom Hughes via talk wrote:
>>>
 No it was released in June 2020. October 2021 was the last
 security patches.

 To answer the original question there have been any deliberate
 changes that I know but given the error it's entirely possible
 that FF has fixed something in what CSP rules it checks for what
 requests.

>>>
>>> I doubt that since FF did not see any changes here for some time,
>>> unfortunately. So it appears to be from an OSM editor's change.
>>>
>>
>> I think you misunderstood what I was saying.
>>
>> My hypothesis is that something in iD has started using a data URL
>> where it didn't before and that is triggering a latent bug in your
>> version of firefox (in that it is checking that URL against the
>> media-src rule in our security policy) while newer versions of
>> firefox are checking it against some other rule.
>>
>
> Thanks - that does clarify the issue. But as you say, "something in iD
> has started" - so it's a change within OSM's editor, which does break
> old systems.
>
> Maybe it's a reasonable and necessary change for ID - but maybe it isn't!
>
>
>> Without knowing more about which load is being blocked it's not
>> really possible to say more and I might be totally wrong as I'm
>> just guessing from the limited information available.
>>
>
>
> I agree - but I don't know where else to report this malfunction. It's
> obvious that one part of this bug is an outdated FF version. But that
> does not mean that those have to be excluded.
>
>
If you track down which exact change 
changed things then maybe it would make sense to report it
(You can try older iD versions and revisions)

In general I would strongly recommend
not using such ancient and insecure browser.

You can setup dual booting, get new see
computer, move that setup to VM, replace that software...___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Mateusz Konieczny via talk]

6 paź 2023, 15:42 od talk@openstreetmap.org:

> On 06/10/2023 14:23, Martin Trautmann wrote:
>
>> On 23-10-06 14:24, Tom Hughes wrote:
>>
>>>
>>>
>>> Maybe it would be easy to avoid and maybe it wouldn't but until
>>> we know what the actual problem is we can't tell and none of the
>>> developers are likely to have such an old browser to reproduce
>>> it even if they wanted to so unless you can provide more details
>>> somehow it's not clear what can be done.
>>>
>>
>>
>> Apart from the info given before I do see an
>>
>> Uncaught SyntaxError: expected expression, got '='
>>
>> https://www.openstreetmap.org/assets/id-859874f88bc2e65931793d0d2edfb626917168cd008d86196e5b6fe2c88b39d5.js
>>
>> :29:19029 
>> 
>>
>
> That's far more likely to be the main problem but you'd need to
> ask the iD developers if they have any clue what it might be.
>
I really would not bother asking people
about bugs present only in ancient, EOL
browsers (unless some project promises to
support browser not supported by even
maker of this browser)___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk