Modify

Opened 10 years ago

Closed 7 years ago

#10387 closed enhancement (fixed)

Boundary for validation rules, styles etc.

Reported by: naoliv Owned by: Don-vip
Priority: major Milestone: 16.12
Component: Core Version:
Keywords: mapcss Cc: jgpacker, lists@…, skyper, Klumbumbus, bastiK, plepe, openstreetmap.org-user-d1g

Description

Like we have <bounds> + <shape> for imagery, couldn't we have a similar mechanism for validation rules?
The logic for this is that some rules only apply to a specific limit/area and users could inadvertently apply them outside this boundary.
Example: an user could enable the Brazilian rules and wrongly validate (and modify) data outside Brazil.

Attachments (1)

Boundaries.zip (212.9 KB ) - added by Don-vip 7 years ago.

Download all attachments as: .zip

Change History (101)

comment:1 by Don-vip, 10 years ago

Keywords: mapcss added

Maybe rendering rules could also benefit from this: we could create custom rules that only apply to a given geographic area.

comment:2 by jgpacker, 10 years ago

Cc: jgpacker added

comment:3 by Aun Johnsen <lists@…>, 10 years ago

Cc: lists@… added

comment:4 by skyper, 10 years ago

Cc: skyper added

comment:5 by simon04, 8 years ago

Milestone: 15.10

Is there a suggestion concerning syntax? What about:

  • [@bbox=1,2,3,4] as a special condition of a rule?
  • bounds key in the meta {} section?

Do we need non-rectangular bboxes polygons?

comment:6 by Klumbumbus, 8 years ago

Cc: Klumbumbus added

comment:7 by simon04, 8 years ago

Cc: bastiK plepe added

comment:9 by simon04, 8 years ago

Milestone: 15.1015.11

Postpone. Feedback is welcome :).

comment:10 by simon04, 8 years ago

Milestone: 15.11

No use-case, no syntax (comment:5), no milestone ;-)

comment:11 by anonymous, 8 years ago

Oops.

The use case is for specific rules for specific places.
Example: The postal codes in Brasil have to obey a certain pattern.

Not sure about the syntax, but I think we should prefer a syntax that makes it easier to specify various rules for a certain area.

comment:12 by Don-vip, 8 years ago

Actually I'm trying something but it takes some time to check if it's possible. Stay tuned.

comment:13 by Don-vip, 8 years ago

Owner: changed from team to Don-vip

comment:14 by bastiK, 8 years ago

Technically, this is similar to left- and right-hand-traffic areas of the world.

comment:15 by Don-vip, 8 years ago

Milestone: 16.07

comment:16 by Don-vip, 8 years ago

Milestone: 16.0716.08

comment:17 by Don-vip, 8 years ago

Milestone: 16.0816.09

comment:18 by Don-vip, 7 years ago

Milestone: 16.0916.10

comment:19 by simon04, 7 years ago

Milestone: 16.1016.11

Milestone renamed

comment:20 by openstreetmap.org-user-d1g, 7 years ago

We need possibility to disable/enable:

based on current country in Help/MapView. It would be better if rules would be auto-enabled auto-disabled without explicit user action.

Simple check for country is what we need the most. We might extend this to support custom areas later.

in reply to:  5 comment:21 by openstreetmap.org-user-d1g, 7 years ago

Replying to simon04:

Is there a suggestion concerning syntax?

I guess we need to support country_code + admin_level first (ISO 3166-2). Usually laws and local organizations postulate all/majority of differences in data: e.g. different traffic signs in each country.

I don't think we have actual "rules" defined by bbox IRL - please let me know if I'm wrong.

comment:22 by openstreetmap.org-user-d1g, 7 years ago

Simplest possibility is to maintain geometry of every country internally and test it against viewport bbox (4 coordinates or just 1 center).

But I'm not sure how easy it is to use JTS with JOSM:

within(Geometry g)

RAW country data is rather heavyweight, some details:

But it may be simplified using web tool here: http://polygons.openstreetmap.fr/index.py?id=60189 (simplified down to 5671 nodes using X=-0.040000)
Or taken from here (quite old 2014 data): http://www.imagico.de/map/boundaries_download_en.php
Or re-created using GIS.

comment:23 by openstreetmap.org-user-d1g, 7 years ago

Cc: openstreetmap.org-user-d1g added

comment:24 by openstreetmap.org-user-d1g, 7 years ago

Component: Core validatorCore
Priority: normalmajor
Summary: Boundary for validation rulesBoundary for validation rules, styles etc.

comment:25 by Don-vip, 7 years ago

I have already a working file with all countries geometries, simplified so the whole world is covered with 11549 nodes (1.67 Mb uncompressed, 281Kb compressed).

I plan to support ISO3166-1-alpha2 and ISO3166-1-alpha3.

Last edited 7 years ago by Don-vip (previous) (diff)

comment:26 by openstreetmap.org-user-d1g, 7 years ago

What JOSM should do if multiple countries displayed in Help/MapView?

I don't think we have good answer yet and any option I had in my mind would be too complex to implement quickly.

I would like to see support of "single country in Help/MapView" as the most beneficial case first.

comment:27 by bastiK, 7 years ago

For validator rules and mappaint styles, it can evaluated for each primitive separately (using GeoPropertyIndex.java). For presets I'm not sure if it is a terribly good idea to hide certain presets depending on the map location.

comment:28 by Aun Johnsen <lists@…>, 7 years ago

I don't think hide presets are desired, but suggesting presets or making buttons on menu bar "inactive" might be possible options. Any installed preset should always be available from the menu.

Maybe have an preference option for behaviour of presets based on geo-location and type?

in reply to:  27 comment:29 by openstreetmap.org-user-d1g, 7 years ago

Replying to bastiK:

For presets I'm not sure if it is a terribly good idea to hide certain presets depending on the map location.

  1. I think we shouldn't display all of Traffic signs_XX Presets. I was told that there 29 of them now. Few users visit that many countries in their life (tourists, journalists, activists etc)

My understanding was that separation started by yopaseopor is okay if there a person to maintain each preset. Over time we will have more contributors to support less popular countries (presets/styles etc).

  1. Even if there only one Brazilian preset/style/plugin, it makes no sense to suggest it outside Brazil.

in reply to:  28 ; comment:30 by openstreetmap.org-user-d1g, 7 years ago

Replying to Aun Johnsen <lists@…>:

Any installed preset should always be available from the menu.

You wouldn't visit/map that many countries in your life, see my answer above. Interface will be cluttered with 10s and 100s of irrelevant icons.

My understanding that very few users would like to access all country-specific presets (mainly style/preset/plugin developers themself).

in reply to:  30 ; comment:31 by Aun Johnsen <lists@…>, 7 years ago

Replying to openstreetmap.org-user-d1g:

Replying to Aun Johnsen <lists@…>:

Any installed preset should always be available from the menu.

You wouldn't visit/map that many countries in your life, see my answer above. Interface will be cluttered with 10s and 100s of irrelevant icons.

My understanding that very few users would like to access all country-specific presets (mainly style/preset/plugin developers themself).

That is why is say "installed" presets. I mainly map in Brazil (so Brazilian presets are of interest), but sometimes map in Europe, so some European presets would also be of interest. I would for example not be interested in installing a Japanese preset as I havn't had any mapping activity there yet.

in reply to:  31 comment:32 by openstreetmap.org-user-d1g, 7 years ago

Replying to Aun Johnsen <lists@…>:

That is why is say "installed" presets.

I suggested to activate presets only when they are relevant: European in Europe, Asian in Asia, Japanese in Japan. (See my comment No20)

"Installation" is not necessary for country-specific presets: simply zoom in where you want to map and you're ready to go (menus/presets will be updated).

We can make single preset/style/plugin applicable to multiple locations at once, this isn't big problem (programmatically).

Could you please explain when European-only presets make sense outside Europe?

comment:33 by Aun Johnsen <lists@…>, 7 years ago

Where local presets are incomplete, European or North American presets can be fall-back since most regional tagging schemes are derived from these, also with larger user mass, changes in tagging consensus are picked up quicker in Europe.

I.e. most countries that have been UK colony would make sense to use UK presets if no local exists, same with US in most of Americas.

comment:34 by openstreetmap.org-user-d1g, 7 years ago

First, let me draw what is "country-specific" preset/style/plugin:

Country-specific:

  • Highway codes (everything related e.g. traffic signs)
  • Boundaries, Administrative divisions
  • Laws
  • Cadastre (cadastre plugin and data are different, even some of them may be OGC complaint)
  • operator/owner tags
  • opening hours holidays (religious, social and political events are different)

Not country specific:

  • drinking_water
  • spring
  • pet shop
  • opening hours general syntax

"changes in tagging consensus are picked up quicker in Europe."

Most of the OSM users located in Europe, but there differences in laws we simply cannot decide in Europe, because they are written in Japanese law/Highway code. You simply can't solve this, but to delegate to local community with more local knowledge and resources.

in reply to:  33 comment:35 by openstreetmap.org-user-d1g, 7 years ago

Replying to Aun Johnsen <lists@…>:

Where local presets are incomplete

Most of them are not written; but some (Traffic Signs) are decent.

European or North American presets can be fall-back since most regional tagging schemes are derived from these, also with larger user mass, changes in tagging consensus are picked up quicker in Europe.

Who decides "NA" highway code? Every state within USA has it's own unique Highway code:

https://en.wikipedia.org/wiki/File:Legality_of_left_turn_on_red_in_USA.svg

Traffic signs are most likely to be common within one country (USA).

comment:36 by Aun Johnsen <lists@…>, 7 years ago

I am sure getting the ability to create national/regional presets would fill in a lot of the missing national/regional presets, such as your example with highway tagging. The thing is that most of these are currently missing, so either a generic tagging, or a system of fall-back would be in its place.

I am sure the most active communities, and those with the tagging schemes most differing from the generic will quickly be solved.

comment:37 by Don-vip, 7 years ago

Here's my working file (286kb compressed). It contains geometries for all entries of ISO3166-1, including special entries such as European Union. All left-driving countries are tagged, so it could replace our driving database (8kb compressed). It's basically the same size as two language files, so I guess it's ok?

Last edited 7 years ago by Don-vip (previous) (diff)

comment:38 by bastiK, 7 years ago

Looks good, +1 on including a file of that size. You can round the coordinates after 3 decimals, which should reduce the size further.

What is the source of data?

comment:39 by GerdP, 7 years ago

Please check: The file has an unclosed way named "Büsingen am Hochrhein"

in reply to:  38 ; comment:40 by Don-vip, 7 years ago

Replying to bastiK:

You can round the coordinates after 3 decimals, which should reduce the size further.

How can I easily do that?

What is the source of data?

Geometry is hand-drawn from OSM imagery. Everything else come from Wikipedia and ISO website.

comment:41 by Don-vip, 7 years ago

Before looking at possible syntax, I'm thinking about what we could do regarding ISO3166-2 (countries subdivisions).
Full ISO3166-2 compliance is out of question. With more than 4000 entries according to Wikipedia, the resulting file would simply become monstruous. We would need subdivisions only for states where the subdivisions have a high legislative power impacting tagging, for example if they can decide on their own about speed limits or other interesting features. This is the case for United States for example, so maybe we could add relevant subdivisions of contemporary federations, on a case by case if we need them.

comment:42 by Don-vip, 7 years ago

@naoliv: Do the 26 Federative units of Brazil impact OSM data in any way?
@bastiK: same question for Germany's länder
@simon04: same question for Austria :)

comment:43 by Klumbumbus, 7 years ago

Nice file.
There is an intersection of ways at the northern corner of Great Britain. I think the lines should not intersect, since a node in this small triangle would belong to two countries.

Some country multipolygons (USA, EU, Netherlands and France (found with validator)) have multipolygons as members with the role outer. Is this intended and will it work as expected?

in reply to:  42 comment:44 by naoliv, 7 years ago

Replying to Don-vip:

@naoliv: Do the 26 Federative units of Brazil impact OSM data in any way?

It's the same law and rules for the whole country here.
We won't need specific rules for each unit.

in reply to:  42 comment:45 by Klumbumbus, 7 years ago

Replying to Don-vip:

same question for Germany's länder

It could be useful. E.g. the Bundesländer (=länder) can decide about the access at forest tracks. In the Bundesland Baden-Württemberg you are allowed to ride the bike in the forest only on tracks with width>2 m or if explicitly allowed.
(see https://forum.openstreetmap.org/viewtopic.php?id=29368 and https://vm.baden-wuerttemberg.de/de/ministerium/presse/pressemitteilung/pid/fragen-und-antworten-zum-mountainbike-fahren-im-wald/)

in reply to:  40 comment:46 by bastiK, 7 years ago

Replying to Don-vip:

Replying to bastiK:

You can round the coordinates after 3 decimals, which should reduce the size further.

How can I easily do that?

$ <Boundaries.osm >Boundaries-nn.osm python -c "import sys, re
for l in sys.stdin:
    print re.sub(r'\d*\.\d{3,}', lambda x: str(round(float(x.group()), 3)), l),"

Replying to Don-vip:

@naoliv: Do the 26 Federative units of Brazil impact OSM data in any way?
@bastiK: same question for Germany's länder

I'm sure someone will find it useful.

in reply to:  43 comment:47 by Don-vip, 7 years ago

Replying to Klumbumbus:

Some country multipolygons (USA, EU, Netherlands and France (found with validator)) have multipolygons as members with the role outer. Is this intended and will it work as expected?

This is intended but I don't know if it will work yet.

comment:48 by Klumbumbus, 7 years ago

Is there a reason to support support ISO3166-1-alpha2 and ISO3166-1-alpha3? I think the 2 letter codes are more common. This new country database will only be used by JOSM related code. So everybody can use the 2 letter codes there. Removing the three letter codes would reduce the file size (a little bit).

Last edited 7 years ago by Klumbumbus (previous) (diff)

in reply to:  42 comment:49 by simon04, 7 years ago

Replying to Don-vip:

@simon04: same question for Austria :)

I don't think this is necessary.

The dataset looks interesting. Would it make sense to add the Wikidata IDs to the boundaries?

comment:50 by openstreetmap.org-user-d1g, 7 years ago

+1 to Wikidata ids, they can be used as PK to add/move/trim data between each dataset.

comment:51 by bastiK, 7 years ago

Considering all the border conflicts and occupations in the world, there is no way we can make well informed and fair judgement for all of them. The only reasonable thing is to use a third party as reference, e.g. what is in the OSM database as result of community process.

Following that, we'd have Crimea part of both Ukraine and Russia. Also, there is a strange ISO3166-1:alpha3 tag for Kosovo.

FIXME: Baarle (add), Bir Tawil (remove), Nahwa (shift)

in reply to:  51 comment:52 by Don-vip, 7 years ago

Replying to bastiK:

Also, there is a strange ISO3166-1:alpha3 tag for Kosovo.

Fixed

FIXME: Baarle (add),

OMG this is the (geometrically) ugliest town in the world o_O I look how to improve the situation but this is really complex.

Bir Tawil (remove)

Strange one also. Fixed

Nahwa (shift)

Fixed

comment:53 by Don-vip, 7 years ago

Looking at https://en.wikipedia.org/wiki/File:World_Speed_Limits.svg I plan to add ISO3166-2 entries for USA, Canada and Australia.

by Don-vip, 7 years ago

Attachment: Boundaries.zip added

comment:54 by Don-vip, 7 years ago

Concerning the syntax, I propose something similar to Help/Styles/MapCSSImplementation#Stylesettings:

  1. Global boundaries for the whole stylesheet:
meta {
  in : "BR"; /* ISO-3166-1-alpha2 : The rules of this stylesheet apply to Brazil */
}

meta {
  in : "AU"; /* ISO-3166-1-alpha2 : The rules of this stylesheet apply to Australia */
  out : "AU-NT"; /* ISO-3166-2 : The rules of this stylesheet do not apply to Australian Norther Territory */
}

meta {
  in : "FR,DE"; /* ISO-3166-1-alpha2 : The rules of this stylesheet apply to France and Germany */
}

  1. Boundaries for a single rule:
way[in("BR")] {
  ...
}

way[in("AU")][out("AU-NT")] {
  ...
}

way[in("FR,DE")] {
  ...
}

comment:55 by openstreetmap.org-user-d1g, 7 years ago

minor, don't be afraid of complete words: in -> include/inside/within/specific/territory; out -> exclude; otherwise make sense

comment:56 by Don-vip, 7 years ago

Status: newassigned

comment:57 by Don-vip, 7 years ago

In 11240/josm:

see #10387 - refactor various actions and commands so they can be used without data layer

in reply to:  54 comment:58 by Klumbumbus, 7 years ago

Replying to Don-vip:

Concerning the syntax, I propose something similar to Help/Styles/MapCSSImplementation#Stylesettings:

Is this really necessary to declare the areas in every rule? I thought this will be "hardcoded". So you can simply use them.

The syntax for styles and rules could then also be simpler similar to pseudoclasses:

way:BR {...}

way:AU!:AU-NT {...}

way:FR:DE {...}

comment:59 by bastiK, 7 years ago

I prefer Vincent's syntax.

One possible extension is that you can ship an .osm file along with your style (like you would for icons). Then adding

meta {
  areas : "my-boundaries.osm";
}

loads the custom areas. Inside the .osm file there would be (multi-)polygons tagged area_id=... and then you could use it just like the iso codes:

way[in("north_sea")] {
  ...
}

comment:60 by Don-vip, 7 years ago

In 11243/josm:

see #10387 - fix unit tests

comment:61 by Don-vip, 7 years ago

In 11247/josm:

see #9400 - see #10387 - see #12914 - initial implementation of boundaries file, replacing left-right-hand-traffic.osm, discourage contributors to use operator=RFF and operator=ERDF in France (territories rules must be manually eabled on existing installations)

comment:62 by Don-vip, 7 years ago

In 11252/josm:

see #10387 - refactor actions to fix taginfo script

in reply to:  61 ; comment:63 by Klumbumbus, 7 years ago

I didn't try this feature yet, but this is a really great improvement! One more huge feature which makes JOSM a unique editor. Thanks.

Replying to Don-vip:

territories rules must be manually eabled on existing installations

Could that be changed so it is active by default also for existing installations? If not then I expect more than 99% of the current users will not enable it manually in the next years, which would be bad.

comment:64 by Klumbumbus, 7 years ago

I tried to make a new image for left-right-hand-traffic. I used this style with the data/boundaries.osm file:

area[driving_side=left] {
    width: 3;
    fill-color: red;
    color: red;
    major-z-index: 15;
}

There is no other style active. Strange thing is now that the USA becomes red as well. I don't get it why this is happening.
At CTRL+I tab mappaint I see the following:

For the USA outline:

...
> MapCSS-Stil 'new icons3' anwenden

Bereich: |s0.0-Infinity
...
Liste der generierten Stile:
 * LineElemStyle{z_idx=[3.0/-3.0/0.0] width=2.0 realWidth=0.0 color=#ff0000 dashed=null dashedColor=null linejoin=round linecap=round}

For the USA multipolygon:

...
> MapCSS-Stil 'new icons3' anwenden

Bereich: |s0.0-Infinity
...
Liste der generierten Stile:
 * AreaElemStyle{z_idx=[15.0/0.0/0.0] color=#ff0000(alpha=50) fillImage=[null]}

So both line and area get the red color despite there is no style, which adds it.
The area gets the mojor zomm of 15 but not the line.

Maybe some strange things are happenig here because the USA multipolygon touches lon=0?

comment:65 by bastiK, 7 years ago

This is caused by US Virgin islands where they drive on the left side. (Multipolygon style on outer way.)

comment:66 by Klumbumbus, 7 years ago

Ah, OK and the "problem" is the support of old style multipolygons (tags on outer instead of relation), right?

comment:67 by Don-vip, 7 years ago

Don't use the source file but rather the optimized one which is created by JOSM the first time in %USERPROFILE%\AppData\Local\JOSM\cache\left-right-hand-traffic.osm

This method allows to maintain a detailed file but keep the same performance than previous method.

in reply to:  67 comment:68 by Klumbumbus, 7 years ago

Replying to Don-vip:

optimized one which is created by JOSM the first time in %USERPROFILE%\AppData\Local\JOSM\cache\left-right-hand-traffic.osm


There is a small error. Gibraltar has righthandtraffic. (https://en.wikipedia.org/wiki/Gibraltar#Transport)

comment:69 by Klumbumbus, 7 years ago

The TurnLanes-tagging plugin uses the lefthadtraffic database. Does it need an update to support the new location of the left-right-hand-traffic.osm file?

comment:70 by Don-vip, 7 years ago

In 11256/josm:

see #10387 - Gibraltar and British Indian Ocean Territory are the only British territories driving on right side

in reply to:  69 ; comment:71 by Don-vip, 7 years ago

Replying to Klumbumbus:

The TurnLanes-tagging plugin uses the lefthadtraffic database. Does it need an update to support the new location of the left-right-hand-traffic.osm file?

It should not if it only relies on Java API and does no try to load the .osm file itself.

@team: any idea why RightAndLefthandTrafficTest is failing on Jenkins? Is it OK on your machines?

comment:72 by Don-vip, 7 years ago

Also, why JOSM does change all ids on save? (see r11256). Do we have a ticket for this? I only added driving_side=right On Gibraltar and British Indian Ocean Territory objects.

in reply to:  71 comment:73 by bastiK, 7 years ago

Replying to Don-vip:

@team: any idea why RightAndLefthandTrafficTest is failing on Jenkins? Is it OK on your machines?

No idea, works here.

Replying to Don-vip:

Also, why JOSM does change all ids on save? (see r11256). Do we have a ticket for this?

There is a global counter that assigns ids. If you open 2 files and later merge them, it is easier when they do not share negative ids. This can be changed, of course.

comment:74 by Don-vip, 7 years ago

In 11259/josm:

see #10387 - see #12914 - add debug info for failing unit test, remove operator=RFF check as the tag does not exist anymore

comment:75 by bastiK, 7 years ago

What about Iso3166GeoProperty.get(BBox), is it still on your TODO list? :)

comment:76 by Don-vip, 7 years ago

Still on my radar yes but I don't know yet how to implement it. If you know how to do it quickly go ahead :)

comment:77 by bastiK, 7 years ago

In 11264/josm:

refactor GeoProperty implementation of RightAndLefthandTraffic to generic separate class DefaultGeoProperty (see #10387)

comment:78 by bastiK, 7 years ago

Maybe DefaultGeoProperty from [11264] can be used, with a separate GeoPropertyIndex object for each region.

It should also improve runtime if for inside("FR"), you only loop over the French polygons, not every polygon in the database. However, I'm not sure about memory use, i.e. duplicated ways.

comment:79 by aceman, 7 years ago

  1. will this new database be used for some of the existing validations inside JOSM, e.g. check correct direction of a junction=roundabout? Should we file some bugs for those?
  2. has there been decision on the syntax on how to limit mapcss rules and presets to specific countries? Is there a documentation page?

in reply to:  79 comment:80 by Klumbumbus, 7 years ago

Replying to aceman:

  1. will this new database be used for some of the existing validations inside JOSM, e.g. check correct direction of a junction=roundabout? Should we file some bugs for those?

roundabout direction is already checked for about 1.5 - 2 years. The database for lefthandtraffic was included for already a while. Now we have boundaries for every country.

See also #13932. If you have more ideas add them there.

  1. has there been decision on the syntax on how to limit mapcss rules and presets to specific countries? Is there a documentation page?

It is not yet documented. It does not work for presets afaik. (You can't change the preset menu without a restart anyway.) For styles and rules use e.g. [inside("FR")] for France.
You can use all the ISO_3166-1_alpha-2 codes. They are referenced in the boundaries.osm file at https://josm.openstreetmap.de/svn/trunk/data/ You can download and load this file in JOSM to investiugate it. USA, Kanada and Australia have additional boundaries for their subdevisions.

comment:81 by simon04, 7 years ago

In 11266/josm:

see #10387 - Fix build due to r11264

comment:82 by simon04, 7 years ago

In 11267/josm:

see #10387 - Fix build due to r11264

comment:83 by Don-vip, 7 years ago

In 11275/josm:

see #10387 - fix unit test

comment:84 by Klumbumbus, 7 years ago

Regarding Rules we have two options:

comment:85 by Klumbumbus, 7 years ago

Docu added at MapCSSImplementation#Territoryselector. Please enhance if I missed something.

Last edited 7 years ago by Klumbumbus (previous) (diff)

in reply to:  63 ; comment:86 by Klumbumbus, 7 years ago

Replying to Klumbumbus:

Replying to Don-vip:

territories rules must be manually eabled on existing installations

Could that be changed so it is active by default also for existing installations? If not then I expect more than 99% of the current users will not enable it manually in the next years, which would be bad.

Could someone please clarify this one? If it is not possible to activate the territories rules without manual user action, then I rather suggest to remove it again and place the territory specific rules in their fitting mapcss ruleset (deprecated, numeric, geometry, combinations,...)

in reply to:  86 ; comment:87 by Don-vip, 7 years ago

Replying to Klumbumbus:

Could someone please clarify this one? If it is not possible to activate the territories rules without manual user action, then I rather suggest to remove it again and place the territory specific rules in their fitting mapcss ruleset (deprecated, numeric, geometry, combinations,...)

I plan to do it but after we're sure that there's no major performance drawback from auto-enable. For now manual enable is the right way.

in reply to:  87 comment:88 by Klumbumbus, 7 years ago

Replying to Don-vip:

I plan to do it but after we're sure that there's no major performance drawback from auto-enable. For now manual enable is the right way.

OK sounds good, thanks.

comment:89 by Klumbumbus, 7 years ago

My console prints this:

INFO: Validator rule hh has been modified. Reloading rule...
Nov 24, 2016 3:55:59 PM org.openstreetmap.josm.Main error
SEVERE: java.lang.reflect.InvocationTargetException. Cause: java.lang.NullPointerException
java.lang.reflect.InvocationTargetException
	at sun.reflect.GeneratedMethodAccessor56.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.openstreetmap.josm.gui.mappaint.mapcss.ExpressionFactory$ParameterFunction.evaluate(ExpressionFactory.java:1242)
	at org.openstreetmap.josm.gui.mappaint.mapcss.ConditionFactory$ExpressionCondition.applies(ConditionFactory.java:866)
	at org.openstreetmap.josm.gui.mappaint.mapcss.Selector$AbstractSelector.matches(Selector.java:463)
	at org.openstreetmap.josm.gui.mappaint.mapcss.Selector$GeneralSelector.matches(Selector.java:534)
	at org.openstreetmap.josm.data.validation.tests.MapCSSTagChecker$TagCheck.whichSelectorMatchesEnvironment(MapCSSTagChecker.java:414)
	at org.openstreetmap.josm.data.validation.tests.MapCSSTagChecker.getErrorsForPrimitive(MapCSSTagChecker.java:685)
	at org.openstreetmap.josm.data.validation.tests.MapCSSTagChecker.checkAsserts(MapCSSTagChecker.java:790)
	at org.openstreetmap.josm.data.validation.tests.MapCSSTagChecker.addMapCSS(MapCSSTagChecker.java:727)
	at org.openstreetmap.josm.io.FileWatcher.processEvents(FileWatcher.java:148)
	at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.NullPointerException
	at org.openstreetmap.josm.tools.GeoPropertyIndex$GPLevel.get(GeoPropertyIndex.java:81)
	at org.openstreetmap.josm.tools.GeoPropertyIndex.get(GeoPropertyIndex.java:49)
	at org.openstreetmap.josm.tools.Territories.getIso3166Codes(Territories.java:81)
	at org.openstreetmap.josm.gui.mappaint.mapcss.ExpressionFactory$Functions.inside(ExpressionFactory.java:968)
	... 13 more

URL:http://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2016-11-23 23:39:53 +0100 (Wed, 23 Nov 2016)
Build-Date:2016-11-24 02:33:36
Revision:11302
Relative:URL: ^/trunk

Identification: JOSM/1.5 (11302 en) Windows 7 32-Bit
Memory Usage: 566 MB / 870 MB (117 MB allocated, but free)
Java version: 1.8.0_111-b14, Oracle Corporation, Java HotSpot(TM) Client VM
Screen: \Display0 1680x1050
Maximum Screen Size: 1680x1050
VM arguments: [-Djava.security.manager, -Djava.security.policy=file:<java.home>\lib\security\javaws.policy, -DtrustProxy=true, -Djnlpx.home=<java.home>\bin, -Djnlpx.origFilenameArg=C:\Program Files\josm-latest-bla.jnlp, -Djnlpx.remove=true, -Djava.util.Arrays.useLegacyMergeSort=true, -Djnlpx.heapsize=256m,900m, -Djnlpx.splashport=62403, -Djnlpx.jvm=<java.home>\bin\javaw.exe, -Djnlpx.vmargs=LURqYXZhLnV0aWwuQXJyYXlzLnVzZUxlZ2FjeU1lcmdlU29ydD10cnVlAA==]
Dataset consistency test: No problems found

comment:90 by bastiK, 7 years ago

Resolution: fixed
Status: assignedclosed

In 11360/josm:

fixed #10387 - efficiency for "inside(...)" function in MapCSS

comment:91 by bastiK, 7 years ago

The "inside(...)" query in MapCSS should be fast now (similar to right-left hand traffic).

in reply to:  90 comment:92 by GerdP, 7 years ago

Replying to bastiK:

In 11360/josm:

fixed #10387 - efficiency for "inside(...)" function in MapCSS

I wonder why you added the code in Geometry. My understanding is that getCombinedPolygons() already describes the area with subtracted inners. The "trick" is the statement this.poly.setWindingRule(Path2D.WIND_EVEN_ODD); in Multipolygon .
Did I get this wrong?

comment:93 by bastiK, 7 years ago

Are you referring to PolyData.get()? Problem with this, it is in EastNorth and not lat/lon.

comment:94 by GerdP, 7 years ago

I wanted to point out that area.subtract() is a costly operation and that getAreaLatLon(List<Node> polygon) might also use
the trick with the winding rule. This is much faster for complex mp-relations.

comment:95 by bastiK, 7 years ago

In 11361/josm:

see #10387 - use path winding rule instead of Area.subtract

in reply to:  94 comment:96 by bastiK, 7 years ago

Replying to Gerd Petermann <gpetermann_muenchen@…>:

I wanted to point out that area.subtract() is a costly operation and that getAreaLatLon(List<Node> polygon) might also use
the trick with the winding rule. This is much faster for complex mp-relations.

Yes, this is probably better.

comment:97 by Klumbumbus, 7 years ago

Resolution: fixed
Status: closedreopened
Last edited 7 years ago by Klumbumbus (previous) (diff)

comment:98 by bastiK, 7 years ago

Isn't this activated by default? If not, how can it be turned on?

comment:99 by Klumbumbus, 7 years ago

I had to manually activate it in the validator preferences, tab "Tag checker rules" (german "Eigenschaftsprüfer-Regeln").

comment:100 by Don-vip, 7 years ago

Milestone: 16.1116.12

Milestone renamed

comment:101 by Don-vip, 7 years ago

Resolution: fixed
Status: reopenedclosed

In 11424/josm:

fix #10387, fix #12914 - enable territorial rules by default

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Don-vip.
as The resolution will be set.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.