#7867 closed defect (fixed)
undetected Zero nodes after redaction process
Reported by: | anonymous | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Core | Version: | |
Keywords: | template_report | Cc: |
Description
Impossible to work with histories, or looking out own history of modifications (in the window about modification groups).
Note : I am just searching for MY own history. I have accepted the ODBL.
Severe havoc where there are parts of JOSM that still want lat/lon attributes on deleted nodes (those that were marked as hidden, actually saved with lat/lon=0 and incorrectly reverted by the bot multiple times with the visible attribute).
Repository Root: http://josm.openstreetmap.de/svn Build-Date: 2012-07-03 01:31:22 Last Changed Author: simon04 Revision: 5315 Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b URL: http://josm.openstreetmap.de/svn/trunk Last Changed Date: 2012-07-02 14:51:19 +0200 (Mon, 02 Jul 2012) Last Changed Rev: 5315 Identification: JOSM/1.5 (5315 fr) Memory Usage: 1497 MB / 2714 MB (419 MB allocated, but free) Java version: 1.7.0_05, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM Operating system: Windows 7 Dataset consistency test: [WARN - ZERO NODES] Way {Way id=45334539 version=2 VT nodes=[]} has zero nodes Plugin: cadastre-fr (28412) Plugin: epci-fr (26960) Plugin: licensechange (28412) Plugin: mapdust (28412) Plugin: merge-overlap (28412) Plugin: multipoly-convert (28412) Plugin: openstreetbugs (28412) Plugin: osmarender (28412) Plugin: reltoolbox (28412) Plugin: reverter (28412) Plugin: undelete (28416) Plugin: waydownloader (28412) org.openstreetmap.josm.io.OsmTransferException: org.openstreetmap.josm.io.OsmDataParsingException: L’attribut obligatoire 'lat' est manquant. (à la ligne 458, colonne 144) at org.openstreetmap.josm.io.OsmServerChangesetReader.downloadChangeset(OsmServerChangesetReader.java:192) at org.openstreetmap.josm.gui.dialogs.changeset.ChangesetContentDownloadTask.realRun(ChangesetContentDownloadTask.java:178) at org.openstreetmap.josm.gui.PleaseWaitRunnable.doRealRun(PleaseWaitRunnable.java:82) at org.openstreetmap.josm.gui.PleaseWaitRunnable.run(PleaseWaitRunnable.
Attachments (0)
Change History (7)
comment:1 by , 12 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
follow-up: 4 comment:3 by , 12 years ago
Actually this bug has been closed as duplicate too early. It was NOT a duplicate of 7505 and 7847. It was not fixed in r5346 but several hours in r5348 AFTER this bug was closed as a duplicate.
So the actual fix was really in r5348 (which concerned the ChangeSet parser, not the geometry primitive builders covered by # 7505, which now groups all changes related to the licence upgrade, and the OSM data parser covered in bug #7847 and not completely fixed for now).
It looks like #7505 is actually a tracking bug for several separate issues that will affect distinct parts of the code (such as incorrect assumptions that some properties are mandatory in historic data).
Somme other affected plugins are those that are exploring/comparing versions, or restoring incorrectly deleted data, or reversing changes. Some of the logic needed in those plugins should apply the rules adopted for the redaction bot. And bugs in those logics reported to the bot maintainer should as well be fixed in other tools and plgins. We need a better technical specification of these rules (because we also see quirks happening).
follow-ups: 5 6 comment:4 by , 12 years ago
Replying to verdy_p@…:
Actually this bug has been closed as duplicate too early. It was NOT a duplicate of 7505 and 7847.
You're right, it was a separate bug. That's why, in the comment just above your message, you may see the following:
Résolution modifié de duplicate à fixed
It was not fixed in r5346 but several hours in r5348 AFTER this bug was closed as a duplicate.
What you're saying is absurd. If you read r5346 svn comment you should see that this bug has been fixed in it, and that r5348 is on a completely different subject.
bug #7847 and not completely fixed for now).
That's right. And any help is welcome on this subject (the problem reported by Stefan).
It looks like #7505 is actually a tracking bug for several separate issues that will affect distinct parts of the code (such as incorrect assumptions that some properties are mandatory in historic data).
I created #7505 some time ago to track all technical changes that would have to be done during the license change process (i.e. redaction).
#7847 has been created right after the unexpected OSM API change that removed lat/lon coordinates in deleted nodes.
comment:5 by , 12 years ago
Replying to Don-vip:
Replying to verdy_p@…:
Actually this bug has been closed as duplicate too early. It was NOT a duplicate of 7505 and 7847.
You're right, it was a separate bug. That's why, in the comment just above your message, you may see the following:
Résolution modifié de duplicate à fixedIt was not fixed in r5346 but several hours in r5348 AFTER this bug was closed as a duplicate.
What you're saying is absurd. If you read r5346 svn comment you should see that this bug has been fixed in it, and that r5348 is on a completely different subject.
I've been confused by the version number of the available compiled download. Sorry.
But please avoid impolite words like "absurd".
The change that is now part of r5346 was still not within it the last time I checked the source of the ChangeSet parser using the web interface to your SVN repository (possibly an effect of your server-side caching proxy, as it was not in my local caches for sure). I was navigating the diffs in that parser code.
follow-up: 7 comment:6 by , 12 years ago
Replying to Don-vip:
Replying to verdy_p@…:
Actually this bug has been closed as duplicate too early. It was NOT a duplicate of 7505 and 7847.
You're right, it was a separate bug. That's why, in the comment just above your message, you may see the following:
Résolution modifié de duplicate à fixed
Sorry for the mess.
Closed as duplicate of #7505.
Please use latest or what two more days.