#10761 closed defect (othersoftware)
osm file open: Shared borders represented as duplicated ways.
Reported by: | StefanB | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Core | Version: | |
Keywords: | template_report | Cc: |
Description
Similar to #10743, but with .osm file as input
tested with JOSM 7725 (latest dev version, with #10743 fixed) and 7643 (stable)
See attached example.
What steps will reproduce the problem?
- Generate a shp file
- Convert a shp file to osm using ogr2osm
- open osm file in JOSM
What is the expected result?
.osm file is read in nicely
What happens instead?
JOSM validation reports many duplicated ways
Please provide any additional information below. Attach a screenshot if possible.
Not sure if this should be fixed in ogr2osm or can/should be fixed in JOSM, or at least have an easy way to fix such data, merging duplicate ways.
Revision: 7726 Repository Root: http://josm.openstreetmap.de/svn Relative URL: ^/trunk Last Changed Author: bastiK Last Changed Date: 2014-11-16 18:08:07 +0100 (Sun, 16 Nov 2014) Build-Date: 2014-11-17 02:33:58 URL: http://josm.openstreetmap.de/svn/trunk Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b Last Changed Rev: 7726 Identification: JOSM/1.5 (7726 en) Windows 7 64-Bit Memory Usage: 659 MB / 1799 MB (155 MB allocated, but free) Java version: 1.8.0_25, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM VM arguments: [-Djava.security.manager, -Djava.security.policy=file:C:\Program Files\Java\jre1.8.0_25\lib\security\javaws.policy, -DtrustProxy=true, -Djnlpx.home=<java.home>\bin, -Djnlpx.origFilenameArg=C:\Users\stefan\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\31\583aa85f-34a79c1f, -Djnlpx.remove=false, -Djava.util.Arrays.useLegacyMergeSort=true, -Djnlpx.splashport=58279, -Djnlp.application.href=https://josm.openstreetmap.de/download/josm-latest.jnlp, -Djnlpx.jvm=<java.home>\bin\javaw.exe, -Djnlpx.vmargs=LURqYXZhLnV0aWwuQXJyYXlzLnVzZUxlZ2FjeU1lcmdlU29ydD10cnVlAC1Eam5scC5hcHBsaWNhdGlvbi5ocmVmPWh0dHBzOi8vam9zbS5vcGVuc3RyZWV0bWFwLmRlL2Rvd25sb2FkL2pvc20tbGF0ZXN0LmpubHAA] Dataset consistency test: No problems found Plugins: - SimplifyArea (30791) - geotools (30762) - jts (30762) - opendata (30796) - utilsplugin2 (30762) Last errors/warnings: - W: Detected deprecated 'canvas{background-color}' in 'https://github.com/bastik/mapcss-tools/raw/osm/mapnik2mapcss/osm-results/mapnik.zip' which will be removed shortly. Use 'fill-color' instead.
Attachments (1)
Change History (6)
by , 10 years ago
Attachment: | split36diss.osm.zip added |
---|
comment:1 by , 10 years ago
I think those duplicated ways can be safely merged if their IDs are negative, as only positive IDs may have some meaning outside of the opened .osm file.
comment:2 by , 10 years ago
Resolution: | → othersoftware |
---|---|
Status: | new → closed |
We read .osm files as they are and we won't mess with their data in any way. Please complain to ogr2osm authors, not to JOSM.
comment:3 by , 10 years ago
Thanks, this seem the right thing to do.
I've re-opened the ogr2osm issue: https://github.com/pnorman/ogr2osm/issues/28
follow-up: 5 comment:4 by , 10 years ago
Can this be easily done as a plugin? It would merge duplicated ways with negative IDs. If it is possible to get all the references to a way from the API, then it can be done for positive IDs as well.
comment:5 by , 10 years ago
Replying to StefanB:
Can this be easily done as a plugin?
It could, but we won't do it. As said, we assume .osm files are valid and we won't mess with file contents. It's the writing program responsability to write valid data, not to the reader to implement workarounds and fallbacks.
sample .osm file