Opened 16 years ago

Last modified 14 years ago

#4043 closed enhancement

[patch] Have an 'upload prohibited' flag in .osm files — at Version 8

Reported by: Ldp Owned by: team
Priority: normal Milestone:
Component: Core Version: latest
Keywords: upload prohibit Cc: skyper

Description (last modified by Don-vip)

While working with a few layers in JOSM, it's very easy to start an upload from the wrong layer. If you don't catch it right away, it would mean time lost to revert it, a spot of agony, and no matter the other destructive things that could occur to live OSM data.

I propose to add an upload prohibit flag to .osm files, so when JOSM loads one of them in a layer, and you try to upload, it refuses to do so.

For example: <osm version='0.6' upload='no'>

This prohibit status should also be settable on a layer, through the GUI, so one can protect oneself from inadvertently doing stupid things, and should then be written out when saving the layer.

This would also apply neatly to other test files around, like the osmarender test file.

Change History (9)

comment:1 by avarab@…, 16 years ago

This would be nice, fwiw this is how I hacked up a non-uploadable file:

bzcat ourfootprints-roads.osm.bz2 | perl -pe "s/ id='-(.*?)' / id='1000\$1' version='1000\$1' timestamp='2106-08-08T22:26:50Z' /; s/ ref='.(.*?)'/ ref='1000\$1'/" | bzip2 > ofp.osm.bz2

comment:2 by framm, 15 years ago

I think this is an important concept that we should indeed add to the OSM file format. I thought of a per-object flag, for example <node id="1" ... transient="yes" /> or so. Use cases include:

  • Utilities that generate a pseudo OSM format - like poly2osm or srtm2osm - would set the extra attribute to make sure that their output isn't accidentally uploaded.
  • Utilities that process OSM data in a lossy fashion - e.g. when saving with reduced coordinate precision (osmosis --write-bin) or truncating cut-in-half entities (osmosis --bb) - would also make use of the extra attribute. In the second case, only a fraction of objects in the file would actually have the flag.

To consider:

  • The flag might have to be evaluated in conjunction with the "source" attribute of the <osm> tag, as something downloaded from source A is of course not (usually) uploadable to source B.

comment:3 by stoecker, 15 years ago

There also must be a way to get rid of that flag when uploading is wanted.

comment:4 by bastiK, 15 years ago

We generally trust the user, so this is more like a reminder: "Are you really sure you want to upload this? It could be a bad idea, because: ...".

Including a lengthy message for each object is not practical. If you use some kind of message id, this leads to more complicated file structure. So a single flag per file could be a simpler concept.

comment:5 by simon04, 14 years ago

Ticket #4732 has been marked as a duplicate of this ticket.

comment:6 by Don-vip, 14 years ago

Ticket #4922 has been marked as a duplicate of this ticket.

comment:7 by skyper, 14 years ago

Cc: skyper added

by Don-vip, 14 years ago

Attachment: patch1.diff added

comment:8 by Don-vip, 14 years ago

Description: modified (diff)
Summary: Have an 'upload prohibited' flag in .osm files[patch] Have an 'upload prohibited' flag in .osm files

Here's a first version of a patch adding this prohibit flag. The flag is called upload='true/false' in <osm> tag, with a default value set to true if absent. The flag is not just a warning but effectively blocks JOSM from uploading data from the concerned layer. There is nothing yet in the GUI allowing to toggle the flag, I'd like to hear your thoughts first on this subject, before continuing. I was thinking of introducing the flag toggle only in expert mode, in the layer contextual menu.

Note: See TracTickets for help on using tickets.