#13581 closed defect (fixed)
10966 has forgotten GPX-Colours from previous tested
Reported by: | MKnight | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | 16.10 |
Component: | Core | Version: | tested |
Keywords: | template_report gsoc-core regression layer gpx | Cc: | michael2402 |
Description
What steps will reproduce the problem?
- Add gpx-layer in v 10786
- give the layer the color green
- save layers in session
- start 10966 with this session
What is the expected result?
Gpx-layer should be green like in older versions
What happens instead?
Gpx-layer is violet
Please provide any additional information below. Attach a screenshot if possible.
URL:http://josm.openstreetmap.de/svn/trunk Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b Last:Changed Date: 2016-09-06 00:16:07 +0200 (Tue, 06 Sep 2016) Build-Date:2016-09-05 22:21:00 Revision:10966 Relative:URL: ^/trunk Identification: JOSM/1.5 (10966 de) Windows 7 64-Bit Memory Usage: 393 MB / 1305 MB (201 MB allocated, but free) Java version: 1.8.0_91-b14, Oracle Corporation, Java HotSpot(TM) Client VM Screen: \Display0 1366x768, \Display1 1280x1024 Maximum Screen Size: 1366x1024 Program arguments: [de-josm-kreise.joz] Plugins: + ColorPlugin (1414145445) + Mapillary (32882) + OpeningHoursEditor (32699) + PicLayer (32796) + RoadSigns (32796) + apache-commons (32699) + apache-http (32699) + buildings_tools (32796) + continuosDownload (53) + download_along (32730) + ejml (32680) + geochat (32796) + geotools (32813) + jogl (1.0.46) + jts (32699) + kendzi3d (1.0.190.1) + kendzi3d-resources (0.0.1) + log4j (32699) + measurement (32732) + opendata (32898) + pbf (32865) + public_transport (32796) + reltoolbox (32796) + reverter (32796) + scripting (30730) + tag2link (32699) + terracer (32699) + turnlanes (32796) + turnlanes-tagging (1473089322) + turnrestrictions (32796) + undelete (32699) + utilsplugin2 (32815) + waydownloader (32699) Tagging presets: + https://josm.openstreetmap.de/josmfile?page=Presets/Bus_lanes&zip=1 + https://josm.openstreetmap.de/josmfile?page=Presets/Addr2&zip=1 + https://josm.openstreetmap.de/josmfile?page=Presets/LaneAttributes&zip=1 + https://josm.openstreetmap.de/josmfile?page=Presets/Maxspeed-zones&zip=1 + https://josm.openstreetmap.de/josmfile?page=Presets/ParkingLanes&zip=1 + https://josm.openstreetmap.de/josmfile?page=Presets/Stolpersteine&zip=1 + http://www.country-linedance.de/daten/Verkehrszeichen-vorlage.zip + https://raw.github.com/Flacus/Windrad/master/windrad.xml Map paint styles: - https://josm.openstreetmap.de/josmfile?page=Styles/Coloured_buildings&zip=1 + https://josm.openstreetmap.de/josmfile?page=Styles/Fixme&style&zip=1 + https://josm.openstreetmap.de/josmfile?page=Styles/Modified&style&zip=1 + https://josm.openstreetmap.de/josmfile?page=Styles/Lane_and_Road_Attributes&zip=1 + https://josm.openstreetmap.de/josmfile?page=Styles/Modified&style&zip=1 + https://josm.openstreetmap.de/josmfile?page=Styles/MaxspeedIcons&zip=1 + https://josm.openstreetmap.de/josmfile?page=Styles/NewParkingFeatures&style&zip=1 + https://josm.openstreetmap.de/josmfile?page=Styles/ParkingLanes&style&zip=1 + C:\OSm\JOSM\osmic-josm-style-master\osmic.mapcss - https://josm.openstreetmap.de/josmfile?page=Styles/Highway_Nodes&zip=1 + https://josm.openstreetmap.de/josmfile?page=Styles/Maxspeed&zip=1 + https://raw.githubusercontent.com/species/josm-preset-traffic_sign_direction/master/direction.mapcss + C:\OSm\JOSM\eigene-style.mapcss + https://josm.openstreetmap.de/josmfile?page=Styles/Landcover&zip=1 Last errors/warnings: - W: java.io.IOException: Attribution is not loaded yet - W: java.io.IOException: Attribution is not loaded yet - W: java.io.IOException: Attribution is not loaded yet - W: java.io.IOException: Attribution is not loaded yet - W: java.io.IOException: Attribution is not loaded yet - W: java.io.IOException: Attribution is not loaded yet - W: java.io.IOException: Attribution is not loaded yet - W: java.io.IOException: Attribution is not loaded yet - W: java.io.IOException: Attribution is not loaded yet - W: java.io.IOException: Attribution is not loaded yet
Attachments (3)
Change History (16)
by , 8 years ago
Attachment: | hc_311.png added |
---|
comment:1 by , 8 years ago
Notice: if i "recolour" the gpx in 10966 it will remember at next start in 10966 ... but not in 10786
maybe there was changed the naming in configs ... not good idea...
comment:2 by , 8 years ago
Problem found, in josm was changed the property from
color.layer[EMPTYSPACE]name.gpx
to
color.layer[DOT]name.gpx
thats not bad at all, but why not migrate the empty space to dot?
comment:3 by , 8 years ago
Cc: | added |
---|
comment:4 by , 8 years ago
Keywords: | gsoc-core regression layer gpx added |
---|
comment:5 by , 8 years ago
Milestone: | → 16.09 |
---|
comment:6 by , 8 years ago
Migrating preferences is currently not supported.
We could use the old name as default value - thus allowing you to still use it. But it is a bad idea to do this since we will end in tons of legacy stuff. Currently, all colors start with color.
. I don't think this is a good definition. I would rater have something like:
layer.name-with-dashes.color
Then we can extend it by:
layer.name-with-dashes.opacity
...
comment:7 by , 8 years ago
sounds not good for me.
Sounds like:
we can change it again to other and really better version and you(users) have to change it manually again.
And in a half year we see a really really better way to (re)name it and you have to change it again.
Im not a programmer, but dunno where the problem is to migrate the "older" versions to new. It must be imho the first idea before changing user(!)-pref-names
follow-up: 9 comment:8 by , 8 years ago
I now traced the issue.
The problem is that those specName
s were never encoded in that dot way, the other color properties were.
@team: Should we revert to the old behaviour? The new one only allows english alphanumeric characters. So there would be no difference between chinese and other layer names (Ä vs Ö) and they would thus share the same color.
comment:9 by , 8 years ago
Replying to michael2402:
@team: Should we revert to the old behaviour?
Either that, or implement a migration. But we cannot force users to recreate manually their preferences.
by , 8 years ago
Attachment: | 13581.patch added |
---|
comment:10 by , 8 years ago
attachment:13581.patch contains a old-to-new-color-key migration code. Please review.
comment:11 by , 8 years ago
I'd suggest to check if the new key is already set. If it is, we should skip that one. Other than that it looks fine and should find the old keys.
10786