[josm-dev] validator rule for public_transport=platform

2015-05-07 Thread Jo
Hi,

I'm getting messages from the validator claiming public_transport=platform
can only be used on way or closed_way. This is not true. It can be used
perfectly well on nodes. In that case the node represents the position of
the pole. I just checked it on the wiki.

http://wiki.openstreetmap.org/wiki/Buses

All the poles of Belgian transport companies De Lijn, TEC and MIVB/STIB are
mapped on nodes. If there is a platform, it is mapped, but that doesn't
replace the pole, nor does it get added to the route relations. All the
extra details like name, ref, route_ref etc also remain on the node
representing the pole. The platform ways and the stop_positions are
optional. Nice to have, but not at all crucial. The NODES with

highway=bus_stop
public_transport=platform
bus=yes

railway=tram_stop
public_transport=platform
tram=yes

are what define the bus/tram stops over here and those get the details and
those get added to the route relations.

So please correct the validator rule.

Kind regards,

Polyglot
___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] validator rule for public_transport=platform

2015-05-07 Thread Gertrud Simson
See http://josm.openstreetmap.de/ticket/11414
___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev


[josm-dev] validator / power=line no power=pole|tower

2013-03-20 Thread Florian Lohoff

Hi,

i have a power minor_line which ends in a brick tower like sub_station.
Thus i made a building=yes way for the substation and let the
power=minor_line end on a node on the outer way for the building which
is the obvious thing as just the isolators are mounted to the wall.

Now the josm validator shows me a warning that the minor_lines node does
not contain a power pole or tower which in this case is correct.

I think this is a false warning.

Flo
-- 
Florian Lohoff f...@zz.de


signature.asc
Description: Digital signature
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] validator suggestion: way ends close to other highway

2013-01-02 Thread Martin Koppenhoefer
2013/1/1 colliar colliar4e...@aol.com:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 01/01/13 15:27, Greg Troxel wrote:

 Hi Greg.

 Have a look at https://josm.openstreetmap.de/ticket/6145 and
 https://josm.openstreetmap.de/ticket/6313 and propably some more about this
 subject.


There are also these tickets:
https://josm.openstreetmap.de/ticket/3531
https://josm.openstreetmap.de/ticket/5837

cheers,
Martin

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


[josm-dev] validator suggestion: way ends close to other highway

2013-01-01 Thread Greg Troxel

I've been running the validator over my whole town (roughly 6km x 6km),
trying to fix all the real issues.  Overall it's very helpful.  Except
for the case below, I am able to understand quickly what it finds
problematic.

(I find that the disconnected ways step takes a very long time,
perhaps minutes, compared to a few seconds total for everything else.
So I've disabled it for now.)

I get a lot of warnings for way ends close to other highway.  I get
the general concept - maybe it should be connected - but it seems overly
aggressive about warning.  So maybe I am misunderstanding it, but my
suggestions are:

  * make the distance configurable (so that when faced with 250
warnings, one can set this to 0.5m, or 1m, and find the most likely
cases that need fixing, as opposed to micromapping where you really
can't go from the parking aisle to the nearby road).

  * in the warning dialogue/highlighting, highlight not only the end
node, but the way that is too close, and put the distance in the
dialogue box.

My second suggestion is because I'm often (98% of the time) unable to
figure out what's wrong.  Sometimes the way end that's highlighted is
connected, but is perhaps near some third way that isn't connected.

If people think this validation step doesn't produce lots of false
positives, I can send a specific example.

Greg


pgpA6nPlWrrDe.pgp
Description: PGP signature
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] validator suggestion: way ends close to other highway

2013-01-01 Thread colliar
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/01/13 15:27, Greg Troxel wrote:

Hi Greg.

Have a look at https://josm.openstreetmap.de/ticket/6145 and
https://josm.openstreetmap.de/ticket/6313 and propably some more about this
subject.

Maybe, you can add some info.

JOSM Trac is the better place to report bugs or request enhancement. Please
feel free to open a new ticket with as much information as possible (example
file, screenshot, makeup ...).

Cheers
Colliar

 
 I've been running the validator over my whole town (roughly 6km x 6km), 
 trying to fix all the real issues.  Overall it's very helpful.  Except for
 the case below, I am able to understand quickly what it finds problematic.
 
 (I find that the disconnected ways step takes a very long time, perhaps
 minutes, compared to a few seconds total for everything else. So I've
 disabled it for now.)
 
 I get a lot of warnings for way ends close to other highway.  I get the
 general concept - maybe it should be connected - but it seems overly 
 aggressive about warning.  So maybe I am misunderstanding it, but my 
 suggestions are:
 
 * make the distance configurable (so that when faced with 250 warnings, one
 can set this to 0.5m, or 1m, and find the most likely cases that need
 fixing, as opposed to micromapping where you really can't go from the
 parking aisle to the nearby road).
 
 * in the warning dialogue/highlighting, highlight not only the end node,
 but the way that is too close, and put the distance in the dialogue box.
 
 My second suggestion is because I'm often (98% of the time) unable to 
 figure out what's wrong.  Sometimes the way end that's highlighted is 
 connected, but is perhaps near some third way that isn't connected.
 
 If people think this validation step doesn't produce lots of false 
 positives, I can send a specific example.
 
 Greg
 
 
 
 ___ josm-dev mailing list 
 josm-dev@openstreetmap.org 
 http://lists.openstreetmap.org/listinfo/josm-dev
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEAREIAAYFAlDjJ7QACgkQalWTFLzqsCv7aQCfUc1avu/x1oMphfjecP5K5Aaj
EkQAoObncHld2k8djDzsQlVf8xVrgtBv
=lLuF
-END PGP SIGNATURE-

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator

2012-07-14 Thread Martin Koppenhoefer
2012/7/13 Dirk Stöcker openstreet...@dstoecker.de:
 For these cases open a ticket describing the exact case and your suggestion
 to fix it.


This is the ticket: https://josm.openstreetmap.de/ticket/7478


 An attached patch also helps :-)


I thought it would have to be inserted somewhere here, but couldn't
find the spot:
http://josm.openstreetmap.de/browser/josm/trunk/data/tagchecker.cfg

cheers,
Martin

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator

2012-07-13 Thread Dirk Stöcker

On Thu, 12 Jul 2012, Paul Hartmann wrote:


I'd suggest an alternative: Remember the original version of each
primitive; on upload run 2 passes for the validator: one for the
(reconstructed) original dataset and one for the modified one.

This solution isn't necessarily easier to implement, but it solves
other problems as well: Currently, if you add a tag to a large number
of objects, and later remove that tag, JOSM still keeps the modified
flag for these objects, so they get uploaded and get a version bump,
although the properties remain unchanged. In addition it would be
useful to display the changes made to an object before upload (e.g.
for a large relation; much like svn status). The history GUI could
be reused for this.

This still requires an extension of the data file format used in JOSM,
but I think it's inevitable. There are a couple of other things that
need to be saved to file, e.g. object histories and edit conflicts.
The plain .osm format can be offered as export option instead.


I agree that this would be an overall improvement - To keep server version 
for each changed object. This would allow several improvements including 
prevention of unnecessary changes.


But I still would not reduce the displayed validator warnings. Maybe we 
could add a this one is new by you, e.g. by different color, but overall 
I don't want to reduce the impact of the validator.


Again having a look at my father. When he changes objects and there are 
validator warnings, he will fix them (most of the time :-) But he probably 
never will call validator for the data set to start finding issues.


I think the validator helped a lot to improve the current map. I read the 
discussion in talk-us and especially the crossing ways is not an 
theoretical issue, but is essential to allow proper routing. We had lots 
of these issues some years ago, we have only very few which today 
improving the overall quality a lot.


For me the most disturbing warning is missing name and usually this is 
always right. OSM is missing a lot of names.


In my holidays is used Garmin+OSM for routing:
 * We have very good data (except in south Ireland)
 * Garmin's routing engine and display of routing commands is crap :-)
 * We are missing tons of meta-data like street names

Users changing data need to be notified about this or the situation will 
not change. And a user modifying an object may know the name and can fix 
it. It is not his fault that name is missing, but he may nevertheless be 
in the position to fix the issue.


Todays errors are usually hidden in the data and not clearly visible. And 
not everybody will add an OpenStreetBugs entry when something wrong 
happens on routing. I think the validator is an essential tool and I don't 
want to reduce its impact. And to say it again: We did a lot in the last 
years to make it more userfriendly and I don't like these discussion 
coming up again and again which are based on the assumption that the 
validator is a silly programmers perfection tool. It is not!


Ciao
--
http://www.dstoecker.eu/ (PGP key available)


___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator

2012-07-13 Thread Paul Johnson
On Jul 13, 2012 3:32 AM, Dirk Stöcker openstreet...@dstoecker.de wrote:


 Todays errors are usually hidden in the data and not clearly visible. And
not everybody will add an OpenStreetBugs entry when something wrong happens
on routing. I think the validator is an essential tool and I don't want to
reduce its impact.

I don't use OpenStreetBugs much anymore because it's a real pain to use,
especially via RSS.  Mapdust seems to be used by more data consumers, has
good RSS feeds and a fairly reliable JOSM plugin.  The only major issue is
Skobbler makes it a little too easy to make a useless bug report.
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator

2012-07-13 Thread Dirk Stöcker

On Fri, 13 Jul 2012, Martin Koppenhoefer wrote:


Btw.: What could be improved is the stuff validator knows. The more it
doesn't know, the less useful it becomes, because with lots of
warnings you will not look at the single problem anymore. E.g.
validator complains about tags on nodes (that it thinks are for ways
only) also in conjunction with traffic_sign tags. When mapping
maxspeeds some mappers store the position of the sign (tags:
traffic_sign=maxspeed, maxspeed=60) and not just the speed limit
implications on the way.


For these cases open a ticket describing the exact case and your 
suggestion to fix it. Usually these tickets are fixed very fast except 
there is no clear indication that it really is a bug (i.e. if there are 
different opinions what is right).


An attached patch also helps :-)

E.g. a lot of unknown tags especially in relations could be fixed by 
more relation presets.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)


___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator

2012-07-12 Thread Dirk Stöcker

On Wed, 11 Jul 2012, Frederik Ramm wrote:


 The idea behind this is that users actually fix these issues. When we no
 longer display them, then they wont get fixed at all. The system has
 already been tuned a lot,


Exactly. This is what the newbie will think as well: The system has been 
tuned a lot, this editor is used by thousands of mappers every day, so it 
MUST BE RIGHT and I am responsible for all these bugs! Oh dear!


I believe you mix newbie and dumb person here. Newbie does not mean a 
brainless person, but only one who does not know OSM very well. But he can 
read dialogs and also understand them. If not, then probably JOSM is not 
the right tool for him anyway.



 so that the warnings and errors have few false
 positives and information level is disabled in default.


We're not talking about false positives. We're talking about things that are 
indeed problems that need to be fixed, but we're showing them to the wrong 
person - someone who lacks the necessary time or first-hand information to 
fix them.


Then I agree with Pierre, that we probably need additional help (e.g. wiki 
pages) describing each error and warning and how to fix it. As always 
help is welcome.


The related pages

http://josm.openstreetmap.de/wiki/Help/Preferences/Validator
and
http://josm.openstreetmap.de/wiki/Help/Dialog/Validator
and
http://josm.openstreetmap.de/wiki/Help/HowTo/ValidatorExamples
and
http://josm.openstreetmap.de/wiki/Help/Action/Validate (missing)

need a lot of updating.


 As programmer I say an error is an error and it makes no sense to divide
 it into my error and your error.


Oh yes it does. Because if you have made a change that *causes* a problem, 
and then a message discourages you from uploading at all, then that's not too 
bad. But if you make a change that just happens to lead to *unrelated* 
problems being highlighted, and you then decide to rather not upload your 
change, then this is a loss for OSM.


If a change causes a problem, then the text tells you to upload anyway. 
And later probably ask someone else to check if it is ok. My father doing 
much more mapping than myself from time to time gets such requests to 
verify and/or fix complex situations always helping the people to do it 
themselves the next time.


Problem with errors usually is not the error itself, but the harsh tone 
in OSM when someone made an error. But this is nothing which software can 
change.



 And a beginner getting tons of errors also touched tons of objects
 which probably is no good idea at all when you don't know what you do...


Is it not possible to touch one large object which has e.g. 20 level 
crossings with other ways and then get 20 warnings just because you added a 
tag to that one big thing? At least that's what the guy on talk-us claimed.


Sure it is. And then for US you google (j)osm crossing ways warning and 
find a short help how to proceed in the first link. For other languages it 
is more complicated to find proper help.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)


___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator

2012-07-12 Thread Dirk Stöcker

On Wed, 11 Jul 2012, Pierre Béland wrote:

This over verification may become counterproductive since contributors 
may have the reaction to always ignore validation messages.


People tend to ignore warning dialogs in every type of software. JOSM 
probably is no big exception to this.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator

2012-07-12 Thread Maarten Deen
Is it possible to make an option for the validator so that you can 
choose between validating only touched objects and all objects?
Then put it default on only touched objects for new installations so 
that newbies only see the errors on objects they actually touched.


Regards,
Maarten

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator

2012-07-12 Thread Toby Murray
On Thu, Jul 12, 2012 at 1:44 AM, Maarten Deen md...@xs4all.nl wrote:
 Is it possible to make an option for the validator so that you can choose
 between validating only touched objects and all objects?
 Then put it default on only touched objects for new installations so that
 newbies only see the errors on objects they actually touched.

Like I said, this is already the default behavior on upload. To
validate everything you have to actually click the validate button
manually.

Toby

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator

2012-07-12 Thread Paul Norman
 From: Maarten Deen [mailto:md...@xs4all.nl]
 Subject: Re: [josm-dev] Validator
 
 Is it possible to make an option for the validator so that you can
 choose between validating only touched objects and all objects?
 Then put it default on only touched objects for new installations so
 that newbies only see the errors on objects they actually touched.

By default on upload it only checks touched objects. This still reports
errors that already existed and the user did not create.


___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator

2012-07-12 Thread colliar
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 12/07/12 08:36, Dirk Stöcker wrote:
 On Wed, 11 Jul 2012, Pierre Béland wrote:
 
 This over verification may become counterproductive since contributors
 may have the reaction to always ignore validation messages.
 
 People tend to ignore warning dialogs in every type of software. JOSM
 probably is no big exception to this.

Exactly. I did fix a lot of errors and warnings on one island of the Acores
last week. The errors where all made by newbees with JOSM (pt) and mostly new
objects.

I do not know if there are big differences between the languages (en,de -
pt), but I doubt that this was the reason for unconnected node, doubled nodes,
unconnected roads and crossing roads without common node or layer tag.


There is definitly room for improvements in layout and links to howto to fix
within the dialogue but right know I hope that a user who is confused will
rather ask some others for help than simply ignoring the dialogue or throwing
away his/her changes.

Cheers colliar
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEAREIAAYFAk/+3uYACgkQalWTFLzqsCsevQCgmG96vGnXV87kIBf086Yx5pqJ
S/YAn1TJRxK/zdmOlHUwwDBHPegesSbm
=NhaB
-END PGP SIGNATURE-

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator

2012-07-12 Thread Paul Hartmann
2012/7/11 Frederik Ramm frede...@remote.org:
 Do you think it would be possible to run the validator after data has been
 downloaded and record the list of problems, and then when someone uploads,
 only check for *newly added* problems instead of everything?

 Of course the validator would still, on request, be able to check
 everything, but the automatic hey, are you sure you want to upload this
 check could be reduced to those problems this mapper is really responsible
 for, rather than listing everything that was wrong even before this mapper
 touched it.

If the user can highlight the validation errors that are directly
caused by the local modifications, this is certainly an improvement.

But I'm not so sure about the technical implementation. It doesn't
seem natural to me to validate the entire dataset on download and keep
the errors till some of theses objects are (maybe) uploaded. What if
the edits are saved to a .osm file and reloaded later?

I'd suggest an alternative: Remember the original version of each
primitive; on upload run 2 passes for the validator: one for the
(reconstructed) original dataset and one for the modified one.

This solution isn't necessarily easier to implement, but it solves
other problems as well: Currently, if you add a tag to a large number
of objects, and later remove that tag, JOSM still keeps the modified
flag for these objects, so they get uploaded and get a version bump,
although the properties remain unchanged. In addition it would be
useful to display the changes made to an object before upload (e.g.
for a large relation; much like svn status). The history GUI could
be reused for this.

This still requires an extension of the data file format used in JOSM,
but I think it's inevitable. There are a couple of other things that
need to be saved to file, e.g. object histories and edit conflicts.
The plain .osm format can be offered as export option instead.

Paul

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


[josm-dev] Validator

2012-07-11 Thread Frederik Ramm

Hi,

   there has been a sort-of-complaint about the Validator on talk-us. 
Kevin Kenny wrote,



The data checks in JOSM and Potlatch2 are fine in that they all
indeed highlight potential problems. But the sum total of them
is just overwhelming. Right now, it feels as if I need to rectify
every problem in any object that I've downloaded, to silence
all the complaints from the tools. They seem to lack even the
idea of forward motion - this part of the map isn't perfect,
but at least it's better than what was there before. Instead,
the UI at default settings appears (to a novice) to insist on
perfection.


I've been in the same situation - work on something, upload, and see 
tons of errors for which I am not the least responsible and which I 
cannot (or don't have the patience to) fix now.


As an experienced mapper, I just ignore them of course. But a newbie 
might really find them intimidating, and choose to discard his edit in 
fear of retribution.


Do you think it would be possible to run the validator after data has 
been downloaded and record the list of problems, and then when someone 
uploads, only check for *newly added* problems instead of everything?


Of course the validator would still, on request, be able to check 
everything, but the automatic hey, are you sure you want to upload 
this check could be reduced to those problems this mapper is really 
responsible for, rather than listing everything that was wrong even 
before this mapper touched it.


Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09 E008°23'33


___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator

2012-07-11 Thread Dirk Stöcker

On Wed, 11 Jul 2012, Frederik Ramm wrote:


 The data checks in JOSM and Potlatch2 are fine in that they all
 indeed highlight potential problems. But the sum total of them
 is just overwhelming. Right now, it feels as if I need to rectify
 every problem in any object that I've downloaded, to silence
 all the complaints from the tools. They seem to lack even the
 idea of forward motion - this part of the map isn't perfect,
 but at least it's better than what was there before. Instead,
 the UI at default settings appears (to a novice) to insist on
 perfection.


I've been in the same situation - work on something, upload, and see tons of 
errors for which I am not the least responsible and which I cannot (or don't 
have the patience to) fix now.


As an experienced mapper, I just ignore them of course. But a newbie might 
really find them intimidating, and choose to discard his edit in fear of 
retribution.


Do you think it would be possible to run the validator after data has been 
downloaded and record the list of problems, and then when someone uploads, 
only check for *newly added* problems instead of everything?


Of course the validator would still, on request, be able to check everything, 
but the automatic hey, are you sure you want to upload this check could be 
reduced to those problems this mapper is really responsible for, rather than 
listing everything that was wrong even before this mapper touched it.


The dialog already says:


The following are results of automatic validation. Try fixing these, but 
be careful (don't destroy valid data).


When in doubt ignore them.

...


I think the second sentence already clearly tells what to do with errors 
not caused by yourself.


The idea behind this is that users actually fix these issues. When we no 
longer display them, then they wont get fixed at all. The system has 
already been tuned a lot, so that the warnings and errors have few false 
positives and information level is disabled in default.


As programmer I say an error is an error and it makes no sense to divide 
it into my error and your error.


And a beginner getting tons of errors also touched tons of objects 
which probably is no good idea at all when you don't know what you do...


BTW: Since this text has been added the complaints about validator issues 
has been reduced a lot, so I actually believe people really read and 
understand the text.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)


___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator

2012-07-11 Thread Pierre Béland
Frederik

I agree entirely with you. Working with JOSM editor, recently, I was cutting 
and replacing part of coastlines.  I wanted to be sure to do it right and avoid 
eventual rendering problems.  I was also saving often. Every time I had to go 
through a list of verifications not knowing if my edit was adding anything to 
the list.  


This over verification may become counterproductive since contributors may have 
the reaction to always ignore validation messages.

 
Pierre 



- Mail original -
 De : Frederik Ramm frede...@remote.org
 À : josm-dev@openstreetmap.org josm-dev@openstreetmap.org
 Cc : 
 Envoyé le : Mercredi 11 juillet 2012 11h48
 Objet : [josm-dev] Validator
 
 Hi,
 
    there has been a sort-of-complaint about the Validator on talk-us. Kevin 
 Kenny wrote,
 
  The data checks in JOSM and Potlatch2 are fine in that they all
  indeed highlight potential problems. But the sum total of them
  is just overwhelming. Right now, it feels as if I need to rectify
  every problem in any object that I've downloaded, to silence
  all the complaints from the tools. They seem to lack even the
  idea of forward motion - this part of the map isn't 
 perfect,
  but at least it's better than what was there before. Instead,
  the UI at default settings appears (to a novice) to insist on
  perfection.
 
 I've been in the same situation - work on something, upload, and see tons of 
 errors for which I am not the least responsible and which I cannot (or don't 
 have the patience to) fix now.
 
 As an experienced mapper, I just ignore them of course. But a newbie might 
 really find them intimidating, and choose to discard his edit in fear of 
 retribution.
 
 Do you think it would be possible to run the validator after data has been 
 downloaded and record the list of problems, and then when someone uploads, 
 only 
 check for *newly added* problems instead of everything?
 
 Of course the validator would still, on request, be able to check everything, 
 but the automatic hey, are you sure you want to upload this check 
 could be reduced to those problems this mapper is really responsible for, 
 rather 
 than listing everything that was wrong even before this mapper touched it.
 
 Bye
 Frederik
 
 -- Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09 
 E008°23'33
 
 
 ___
 josm-dev mailing list
 josm-dev@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/josm-dev
 
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator

2012-07-11 Thread Frederik Ramm

Hi,

On 11.07.2012 18:13, Dirk Stöcker wrote:

The dialog already says:


The following are results of automatic validation. Try fixing these, but
be careful (don't destroy valid data).

When in doubt ignore them.

...



I think that, for a newbie, the when in doubt, ignore them line can be 
dwarfed if there's a large number of warnings and errors.



The idea behind this is that users actually fix these issues. When we no
longer display them, then they wont get fixed at all. The system has
already been tuned a lot,


Exactly. This is what the newbie will think as well: The system has 
been tuned a lot, this editor is used by thousands of mappers every day, 
so it MUST BE RIGHT and I am responsible for all these bugs! Oh dear!



so that the warnings and errors have few false
positives and information level is disabled in default.


We're not talking about false positives. We're talking about things that 
are indeed problems that need to be fixed, but we're showing them to the 
wrong person - someone who lacks the necessary time or first-hand 
information to fix them.



As programmer I say an error is an error and it makes no sense to divide
it into my error and your error.


Oh yes it does. Because if you have made a change that *causes* a 
problem, and then a message discourages you from uploading at all, then 
that's not too bad. But if you make a change that just happens to lead 
to *unrelated* problems being highlighted, and you then decide to rather 
not upload your change, then this is a loss for OSM.



And a beginner getting tons of errors also touched tons of objects
which probably is no good idea at all when you don't know what you do...


Is it not possible to touch one large object which has e.g. 20 level 
crossings with other ways and then get 20 warnings just because you 
added a tag to that one big thing? At least that's what the guy on 
talk-us claimed.


Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09 E008°23'33



___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator

2012-07-11 Thread Toby Murray
On Wed, Jul 11, 2012 at 1:00 PM, Frederik Ramm frede...@remote.org wrote:
 Hi,


 On 11.07.2012 18:13, Dirk Stöcker wrote:

 The dialog already says:

 
 The following are results of automatic validation. Try fixing these, but
 be careful (don't destroy valid data).

 When in doubt ignore them.

 ...
 


 I think that, for a newbie, the when in doubt, ignore them line can be
 dwarfed if there's a large number of warnings and errors.


 The idea behind this is that users actually fix these issues. When we no
 longer display them, then they wont get fixed at all. The system has
 already been tuned a lot,


 Exactly. This is what the newbie will think as well: The system has been
 tuned a lot, this editor is used by thousands of mappers every day, so it
 MUST BE RIGHT and I am responsible for all these bugs! Oh dear!


 so that the warnings and errors have few false
 positives and information level is disabled in default.


 We're not talking about false positives. We're talking about things that are
 indeed problems that need to be fixed, but we're showing them to the wrong
 person - someone who lacks the necessary time or first-hand information to
 fix them.


 As programmer I say an error is an error and it makes no sense to divide
 it into my error and your error.


 Oh yes it does. Because if you have made a change that *causes* a problem,
 and then a message discourages you from uploading at all, then that's not
 too bad. But if you make a change that just happens to lead to *unrelated*
 problems being highlighted, and you then decide to rather not upload your
 change, then this is a loss for OSM.


 And a beginner getting tons of errors also touched tons of objects
 which probably is no good idea at all when you don't know what you do...


 Is it not possible to touch one large object which has e.g. 20 level
 crossings with other ways and then get 20 warnings just because you added a
 tag to that one big thing? At least that's what the guy on talk-us claimed.

Yes. The validator runs on any object you have touched so if you add a
node to a TIGER railway to correct its geometry then you will get a
warning for every highway=residential it crosses without an
intersecting node. Personaly, I'm fine with this and even desire it
since most of the time I will go fix things. Or not if I really don't
have time. I can see how it could be daunting for a new user though.
Is there any difference in validator behavior in beginner vs expert
mode? Perhaps something could be done there...

Toby

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] validator question, multipolygons

2011-03-06 Thread Thomas Ineichen
Dirk Stöcker schrieb:

 * unknown relation type (warning) - JOSM should never assume to be in 
 possession of a full list of allowed relation types!

 Right, that it only knows certain types, but making it an Info-text makes 
 it loosing its function. Here the you should be sure if you know better 
 is required for users.

Maybe it would be possible to only warn once and add the relation type to
the list of known relations if it gets uploaded?


Regards,
Thomas


___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] validator question, multipolygons

2011-03-05 Thread Rolf Bode-Meyer
2011/3/4 Frederik Ramm frede...@remote.org:

Other things aside, as a user of JOSM have some comments.

 I'll give some examples for checks that I think are nannying too much, all
 these are active by default:

 * unknown relation type (warning) - JOSM should never assume to be in
 possession of a full list of allowed relation types!

That's annoying for public transport using the Oxomoa scheme which
seems unknown at least for stable JOSM. But in general I find it ok to
warn. I don't perceive Unknown as Unknown as a whole but Unknown
to the JOSM validator. You should pay attention, that's all.

 * unnamed ways (warning) - I think it is perfectly normal to draw streets
 from aerial imagery and have no name for them.

This often saved me from uploading data where I forgot to ad name to
newly traced streets. I think it will do more good than bad. Again,
this is a warning only and only the user can decide.

I second that dialogues should be more modest and don't say Data has
errors. if that isn't dead sure (OTOH, I myself never read the title
text anyway). I'd call it Data may have issues.
I myself am closely paying attention to errors and warnings listed and
think the validator is a strong point of JOSM. But I also ignore stuff
after validating it myself.

Rolf

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] validator question, multipolygons

2011-03-05 Thread Dirk Stöcker

On Fri, 4 Mar 2011, Frederik Ramm wrote:

In my eyes the validator does not have a problem with one specific check; it 
has an attitude problem. Until now I wasn't aware that it was *your* attitude 
I was criticizing when I said so ;) but I think the validator is nannying 
people too much, *especially* (and I checked that before writing it) since it 
is enabled by default on a new install.


I asked some non-development users now and it seems there is an 
understanding problem between the way developers and users view the 
reports. I'm used to error, warning and info methods from a lot of 
development tools like compilers. But it seems most users don't understand 
a warning the same way. So probably we should find a better way to explain 
this situation.


I don't even have to look past the warning dialog for my first complaint: 
Even if the list contains only warnings, the dialog title still reads: 
Data has errors. - That's what I mean by attitude problem; in my eyes it is 
totally wrong to *ever* tell a mapper that his data has errors. The 
validator can at most point out potential problems - but data has errors? 
As an expericed mapper I percieve that to be arrogance on JOSM's part, and as 
a newbie mapper I would certainly not proceed with uploading.


I think after the next release (as it means translation issues) we should 
rephrase the wording and add some short descriptions texts, the validator 
is meant as an advince and it should not patronise.


When people misunderstand that we need to make it clearer.

* untagged way (warning) - perfectly ok if such a way is a relation member. 
You're not showing the warning if it is a multipolygon but there may be 
others you don't know of.


I think this warning is nearly never a false positive. Thus warning status 
is valid.


* unknown relation type (warning) - JOSM should never assume to be in 
possession of a full list of allowed relation types!


Right, that it only knows certain types, but making it an Info-text makes 
it loosing its function. Here the you should be sure if you know better 
is required for users.


* unnamed ways (warning) - I think it is perfectly normal to draw streets 
from aerial imagery and have no name for them.


In most cases it is an mistake. Again this is a problem when the warning 
is misunderstood.


* illegal tag/value combinations - someone seems to have had a field day 
here. 90% of these deserve to be thrown out. Only recently it complained 
about my man_made=pipeline - from reading the source I found out that it 
was expecting an extra tag with details about the pipeline.


Yes. Here finetuning may be necessary. But this is a wide field and no 
generic solution, as each check has individual warning level.


I think the main problem is that the validator is now by default enabled 
before download - something you can switch off, of course, but to the new 
mapper the Your data has errors message conveys: We don't want your data, 
please stop what you're doing!


I agree, that can be a problem. So the solution must be to make clear what 
error, warning and other of JOSM validator really mean. And we need 
to state that in few words, or people wont read it.


Also the online help for this needs extension probably.

It is funny that both of us seem to have a desire to nanny JOSM users, just 
whenever you're doing it I complain and vice versa.


Well, I think we agreed already in the past, that our opinions are equal 
in a lot of places, but we also have fields where we disagree a lot. Not 
that bad a situation at all, as usually it leads to results which are 
better than previous situation.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)


___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] validator question, multipolygons

2011-03-05 Thread Ulf Lamping

Am 05.03.2011 11:51, schrieb Dirk Stöcker:

On Fri, 4 Mar 2011, Frederik Ramm wrote:


In my eyes the validator does not have a problem with one specific
check; it has an attitude problem. Until now I wasn't aware that it
was *your* attitude I was criticizing when I said so ;) but I think
the validator is nannying people too much, *especially* (and I checked
that before writing it) since it is enabled by default on a new install.


I asked some non-development users now and it seems there is an
understanding problem between the way developers and users view the
reports. I'm used to error, warning and info methods from a lot of
development tools like compilers. But it seems most users don't
understand a warning the same way. So probably we should find a better
way to explain this situation.


Yes, rethinking the wording of the message types and the messages 
might be a very good idea.


E.g. unknown relation type (warning): If JOSM has no basis to judge if 
something is right or wrong, this is no good basis to issue a warning, 
this is certainly better an info like: Sorry, I don't know the relation 
type XY.
A different story would be a checker for obvious spelling mistakes: 
Warning: The relation type rout should probably be route - and even 
that should be cautiously done.


Regards, ULFL

P.S: I'm always fixing compiler warnings to avoid later problems, but 
I've switched off the validator some time ago, as it was only a hassle 
and no real help for me.


___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] validator question, multipolygons

2011-03-05 Thread hbogner

On 03/04/2011 10:57 PM, Frederik Ramm wrote:

To understand the severity of this, take this example: You are new to
JOSM. You map a road and tag it highway=road. You hit upload. You get
(emphasis by me):

Data WITH ERRORS. Upload anyway?
+ Warnings
   + ILLEGAL tag/value combinations - temporary highway type

So, highway=road is an error, and an illegal combination of a tag and
value? Thankfully it doesn't complain when I write highway=raod. Maybe I
should use highway=raod instead of highway=road as the latter is clearly
illegal and an error.

I think the main problem is that the validator is now by default enabled
before download - something you can switch off, of course, but to the
new mapper the Your data has errors message conveys: We don't want
your data, please stop what you're doing!


I agree with this, validator should NOT start automaticaly with JOSM.
It shoud have a option to start it when you want.
We lost some new OSM mappers because of this.
Validator was making them angry with its constant warnings, street 
without names, ... and so on, and they stopped mapping.
So please tune(tune, not turn) the validator down, or write extensive 
manual about all the possible error combinations it reports, and what to 
do...

We who use it for years know what to do, but new useras are confused.


___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] validator question, multipolygons

2011-03-05 Thread Russ Nelson
hbogner writes:
  We who use it for years know what to do, but new useras are confused.

I agree. What might work for better nannying is to only run the
validator on things they've changed. Otherwise they get asked to fix
everything within the bounding box they downloaded.

Even better than that would be to do validation continuously. Much
better to catch an error right away.

-- 
--my blog is athttp://blog.russnelson.com
Crynwr supports open source software
521 Pleasant Valley Rd. | +1 315-600-8815
Potsdam, NY 13676-3213  | Sheepdog   

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] validator question, multipolygons

2011-03-05 Thread Lennard

On 5-3-2011 18:37, Mike N wrote:

On 3/5/2011 12:05 PM, Russ Nelson wrote:

I agree. What might work for better nannying is to only run the
validator on things they've changed. Otherwise they get asked to fix
everything within the bounding box they downloaded.


? It already works this way for me.


When you hit upload, yes. If you click Validate in the validator, it 
checks every object.



--
Lennard

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] validator question, multipolygons

2011-03-05 Thread Dirk Stöcker

On Sat, 5 Mar 2011, hbogner wrote:


We lost some new OSM mappers because of this.


If the people are discouraged that easily then they would have gone soon 
anyway. Have you ever got a message/email from someone who thinks that you 
destroyed his work due to a simple modification. The validator is 
harmless compared to this. My father who does a lot more than I do gets 
these messages constantly and I got them a lot when I was more active.


The time for basic mapping is over (at least in Germany and central 
europe) and tools like the validator are more and more important to get a 
useable database. JOSM's goal is not to have to ultimate freedom for a 
mapper. JOSM allows you to do nearly everything, but it does not encourage 
you to do so. The goal is a usable database following some unique 
standards. And it must be easier for a user to follow the standards than 
not to do it.


Maybe in some cases the tests aren't perfectly correct, but this is to be 
expected as automatic detection of these topics is a very complicated 
issue and errors can't be prevented. When you find such problems, report 
them properly and they will be fixed when possible.


If I judge this issue based on the ticket reports we get, than we have 
only minor problems with this. And half of the reports ask to add 
additional checks and not to remove some.


So a note to these of you trying to convince me that we have a major 
problem with validator: This opinion does not match the statistical data 
that we have. Especially as validator had 80% installation count 
even before it moved into core.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)


___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] validator question, multipolygons

2011-03-05 Thread Russ Nelson
Dirk Stöcker writes:
  So a note to these of you trying to convince me that we have a major 
  problem with validator: This opinion does not match the statistical data 
  that we have. Especially as validator had 80% installation count 
  even before it moved into core.

Not valid data because people were told to install the
validator. Better data would be How often do people click No?

-- 
--my blog is athttp://blog.russnelson.com
Crynwr supports open source software
521 Pleasant Valley Rd. | +1 315-600-8815
Potsdam, NY 13676-3213  | Sheepdog   

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] validator question, multipolygons

2011-03-05 Thread Frederik Ramm

Hi,

Dirk Stöcker wrote:
If I judge this issue based on the ticket reports we get, than we have 
only minor problems with this. And half of the reports ask to add 
additional checks and not to remove some.


That's because you have created a perfect user nannying environment and 
people react to that. It's an interesting challenge. Once you see that 
the validator will complain about certain things in a multipolygon 
relation but not about others, you immediately think: Oh well it should 
actually also complain about this, and that. And if someone does that 
together with that we should warn them too. And...


I'm 100% sure that the people who ask for more checks are *not* those 
who say: This error always happens to me and I'd really be happy if the 
editor could tell me. These are the people who say I really think the 
others should be told to map like I do.


So a note to these of you trying to convince me that we have a major 
problem with validator: This opinion does not match the statistical data 
that we have. Especially as validator had 80% installation count even 
before it moved into core.


I'm not sure these statistics can be applied the way you apply them. How 
did you measure installation count? How many of those were 
auto-installed through the Windows installer which AFAIK bundled the 
validator with JOSM? At that time, was the validator already set to 
validate before uploading by default? How has the number and extend of 
checks be changed between then and now? Etc.


Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09 E008°23'33

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] validator question, multipolygons

2011-03-05 Thread Ulf Lamping

Am 05.03.2011 21:27, schrieb Dirk Stöcker:

On Sat, 5 Mar 2011, hbogner wrote:


We lost some new OSM mappers because of this.


If the people are discouraged that easily then they would have gone soon
anyway. Have you ever got a message/email from someone who thinks that
you destroyed his work due to a simple modification. The validator is
harmless compared to this. My father who does a lot more than I do gets
these messages constantly and I got them a lot when I was more active.


Strange, I never got a single message like this since 2007 ...


The time for basic mapping is over (at least in Germany and central
europe)


That's simply untrue, except for big cities.


and tools like the validator are more and more important to get
a useable database. JOSM's goal is not to have to ultimate freedom for a
mapper.


Is this JOSMs goal or your personal?

 JOSM allows you to do nearly everything, but it does not

encourage you to do so. The goal is a usable database following some
unique standards. And it must be easier for a user to follow the
standards than not to do it.


Again, is this JOSMs goal or your personal?

E.g. it is not the goal of OSM (and it should not be the goal of JOSM) 
to warn about unknown relation types.



Maybe in some cases the tests aren't perfectly correct,


The last time I've tested it, the results were unjustified, 
overreacting, not helpful on how to fix it ...



but this is to
be expected as automatic detection of these topics is a very complicated
issue and errors can't be prevented.


As the experienced developer can't handle it, the unexperienced mapper 
has to deal with it - ouch! :-(



When you find such problems, report
them properly and they will be fixed when possible.

If I judge this issue based on the ticket reports we get, than we have
only minor problems with this. And half of the reports ask to add
additional checks and not to remove some.


If most people just switch off the validator because it's just bogus and 
brocken - which it is IMHO, it's no wonder that there are not much 
tickets about it. Why writing a ticket when you can easily get rid of 
that annoying stuff.



If you want to have such a validator, it has to be as perfect as 
possible under all circumstances and the messages have to be very clear 
how to fix the issue. Otherwise it's just a waste of everyones time.


Regards, ULFL

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] validator question, multipolygons

2011-03-05 Thread Dirk Stöcker

On Sat, 5 Mar 2011, Frederik Ramm wrote:


 If I judge this issue based on the ticket reports we get, than we have
 only minor problems with this. And half of the reports ask to add
 additional checks and not to remove some.


That's because you have created a perfect user nannying environment and 
people react to that. It's an interesting challenge. Once you see that the 
validator will complain about certain things in a multipolygon relation but 
not about others, you immediately think: Oh well it should actually also 
complain about this, and that. And if someone does that together with that we 
should warn them too. And...


This is actually irrelevant. The Trac bug report system only catches these 
people who are willing to report anyway. So the absolute count does not 
say a lot (only compared to other reports), but the type of reports we get 
is a useful measure.


I'm 100% sure that the people who ask for more checks are *not* those who 
say: This error always happens to me and I'd really be happy if the editor 
could tell me.


Well - Actually here you are wrong. One example is a person who wants the 
coastline checks moved from OTHER to WARN level, as it still happens often 
that coasts are destroyed.


These are the people who say I really think the others should be told 
to map like I do.


Very likely also this kind exists, but we aren't forced to agree to their 
request.



 So a note to these of you trying to convince me that we have a major
 problem with validator: This opinion does not match the statistical data
 that we have. Especially as validator had 80% installation count even
 before it moved into core.


I'm not sure these statistics can be applied the way you apply them. How did 
you measure installation count? How many of those were auto-installed through


I cannot measure installation count.


the Windows installer which AFAIK bundled the validator with JOSM? At that


Yes. Sure. And exactly this invalidates the opinion that moving validator 
into core changed the situation. Effectively it has been a de-facto core 
component for a long time now.



time, was the validator already set to validate before uploading by default?


This is default as long as I'm involved in JOSM development.


How has the number and extend of checks be changed between then and now? Etc.


The number of tests has been increased. The number of tests the users sees 
in default settings has been decreased a lot.


Whether you and others like it or not - The opinion expressed on 
mailinglists like this (and talk-de and others) is not equal to the 
real-world. Thus I do not base my judgment on these discussions, but I try 
to find better data. And if that data shows me a totally different view, 
then I'm very sceptical.


Software users aren't that dumb as most want to tell me. They are 
usually much more flexible that most of you seem to assume.


P.S. That doesn't mean there shouldn't be improvements in this area.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)


___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] validator question, multipolygons

2011-03-05 Thread Matthias Julius
Lennard l...@xs4all.nl writes:

 On 5-3-2011 18:37, Mike N wrote:
 On 3/5/2011 12:05 PM, Russ Nelson wrote:
 I agree. What might work for better nannying is to only run the
 validator on things they've changed. Otherwise they get asked to fix
 everything within the bounding box they downloaded.

 ? It already works this way for me.

 When you hit upload, yes. If you click Validate in the validator, it
 checks every object.

... if nothing is selected. Otherwise it checks the selection.

I quite like that behavior.

Matthias

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] validator question, multipolygons

2011-03-05 Thread hbogner

On 03/05/2011 09:27 PM, Dirk Stöcker wrote:

The time for basic mapping is over (at least in Germany and central
europe) and tools like the validator are more and more important to get
a useable database.


Germany is NOT the rest of the world, we still have a lot of basic 
maping to do.


Primary roads are almost finished mapping, secondary are at 95% but 
tertiary are at 35%, and there are other roads, and extra tags for every 
road, max speed, width, lanes, surface... :D
Basic mapping will continue for years, Bing is not present evereywhere, 
gpx logs do not cover everything, there are empty places 10's of 
kilometers accros, populated places have only a few main roads, ...


We (group of long time users) need the beginners to map their locations 
as best as they know, adn fill those empty places. Even if it's not 
valid 100%. We have our own scripts that find errors, and there is 
openstreetbugs, keepright, and other tools. We teach new users on the way.


Validator is nice tool, but we have new users who know only basics of 
JOSM. One of them is 60 yeared monutain biker, 56 yeard mountain 
climber, ... :D
I spend hours and hours explaining it to them that roads don't have to 
have a name if they don tknow it and that they can ignore that warning ...



___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] validator question, multipolygons

2011-03-05 Thread hbogner

PS.

I personaly use validator when fixing errors found with other tools, but 
i know how to use it :D



___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


[josm-dev] validator question, multipolygons

2011-03-04 Thread M∡rtin Koppenhoefer
recently I started to use multipolygons to save ways. For instance I
draw a closed way and tag it with barrier=fence. Then I make a
multipolygon-relation where I add the way as outer and assign a
landuse. The Josm-Validator gives me a strange warning about this:
Style for outer way mismatches. What does this mean?

cheers,
Martin

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] validator question, multipolygons

2011-03-04 Thread Frederik Ramm

Hi,

M?rtin Koppenhoefer wrote:

recently I started to use multipolygons to save ways. For instance I
draw a closed way and tag it with barrier=fence. Then I make a
multipolygon-relation where I add the way as outer and assign a
landuse. The Josm-Validator gives me a strange warning about this:
Style for outer way mismatches. What does this mean?


It means that the validator is *much* too over-eager and needs to be 
toned down. I have seen people break their perfect mapping because of it.


Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09 E008°23'33

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] validator question, multipolygons

2011-03-04 Thread M∡rtin Koppenhoefer
2011/3/4 Frederik Ramm frede...@remote.org:
 It means that the validator is *much* too over-eager and needs to be toned
 down. I have seen people break their perfect mapping because of it.


+1 (there is also warnings about close way ends where the way is a
barrier). IMHO JOSM should not encourage people at all to tag the
outer way with area tags and not the multipolygon, even for simple
cases.

I know that you can ignore errors and warnings (permanently in the
validator), but I don't do that because I fear that I might miss a
useful warning, and I guess that other user behave similar, so toning
it down might be a good solution.

cheers,
Martin

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] validator question, multipolygons

2011-03-04 Thread Dirk Stöcker

On Fri, 4 Mar 2011, M∡rtin Koppenhoefer wrote:


recently I started to use multipolygons to save ways. For instance I
draw a closed way and tag it with barrier=fence. Then I make a
multipolygon-relation where I add the way as outer and assign a
landuse. The Josm-Validator gives me a strange warning about this:
Style for outer way mismatches. What does this mean?


Please make an example which shows this. This warning essentially means 
that you have NO style for the multipolygon and multiple outer ways, which 
have different styles. This means that it is not clear what the 
multipolygon actually should be.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] validator question, multipolygons

2011-03-04 Thread M∡rtin Koppenhoefer
2011/3/4 Dirk Stöcker openstreet...@dstoecker.de:
 Please make an example which shows this. This warning essentially means that
 you have NO style for the multipolygon and multiple outer ways, which have
 different styles. This means that it is not clear what the multipolygon
 actually should be.


way 102703913

cheers,
Martin

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] validator question, multipolygons

2011-03-04 Thread Dirk Stöcker

On Fri, 4 Mar 2011, Frederik Ramm wrote:


 recently I started to use multipolygons to save ways. For instance I
 draw a closed way and tag it with barrier=fence. Then I make a
 multipolygon-relation where I add the way as outer and assign a
 landuse. The Josm-Validator gives me a strange warning about this:
 Style for outer way mismatches. What does this mean?


It means that the validator is *much* too over-eager and needs to be toned 
down. I have seen people break their perfect mapping because of it.


Frederik. Most of the time you have valuable comments and ideas, but a 
comment like this is a hit in my face which I don't like.


This warning has sense and I would suggest to have a look into the code 
before issuing such nonsense.


Maybe the code has bugs, but simply saying that I made a lot of crap is 
not the way to go. And yes I take that one a bit personal, as it is 
basically my code.


Validator has been tuned a lot in the last months to reach a proper balance 
between warnings and useful output. All your posts in the last weeks show 
that you don't follow the JOSM develop close enough to have a good 
judgment on these issues. So before blaming all and everything start to 
get more in touch with the recent code base and when necessary file bug 
reports where fine tuning is needed.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)


___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] validator question, multipolygons

2011-03-04 Thread M∡rtin Koppenhoefer
2011/3/4 Dirk Stöcker openstreet...@dstoecker.de:
 Validator has been tuned a lot in the last months to reach a proper balance
 between warnings and useful output. All your posts in the last weeks show
 that you don't follow the JOSM develop close enough to have a good judgment
 on these issues. So before blaming all and everything start to get more in
 touch with the recent code base and when necessary file bug reports where
 fine tuning is needed.


This is all true, and it really is a very useful piece of JOSM, no
doubt. That's why we should try to get rid of warnings that are no
errors, because if there are too many warnings people will simply
ignore all of them (I guess you already know this and see it the same
way). Of course it is not possible that the validator understands
every possible situation on earth which might be mapped correctly.

In this case he would have to know that the barrier=fence is a linear
feature and not describing the area.

Another issue where I get warnings are overlapping areas (which is
not using a multipolygon for adjacent areas, so their ways are partly
overlapping). Personally I ignore them but I know of quite some
situations where other mappers disconnected areas because of this
(also pedestrian areas mapped as squares which connected to a road). I
think that this is not a warning that should be turned on by default,
because validator can't know about the topology, and always using a
multipolygon when 2 areas are touching (to reuse this part of the way)
is overkill.

cheers,
Martin

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] validator question, multipolygons

2011-03-04 Thread Dirk Stöcker

On Fri, 4 Mar 2011, M∡rtin Koppenhoefer wrote:


Please make an example which shows this. This warning essentially means that
you have NO style for the multipolygon and multiple outer ways, which have
different styles. This means that it is not clear what the multipolygon
actually should be.


way 102703913


Seems to be a bug. During the code moving around of code between 
multipolygon drawing and validator this must have bee mix up.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] validator question, multipolygons

2011-03-04 Thread Dirk Stöcker

On Fri, 4 Mar 2011, M∡rtin Koppenhoefer wrote:


Another issue where I get warnings are overlapping areas (which is
not using a multipolygon for adjacent areas, so their ways are partly
overlapping). Personally I ignore them but I know of quite some
situations where other mappers disconnected areas because of this
(also pedestrian areas mapped as squares which connected to a road). I
think that this is not a warning that should be turned on by default,
because validator can't know about the topology, and always using a
multipolygon when 2 areas are touching (to reuse this part of the way)
is overkill.


This is already an informational warning which is not shown by default.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] validator question, multipolygons

2011-03-04 Thread Frederik Ramm

Dirk,

Dirk Stöcker wrote:
Maybe the code has bugs, but simply saying that I made a lot of crap is 
not the way to go. And yes I take that one a bit personal, as it is 
basically my code.


I wasn't aware of this, I thought it had been done by someone else. I 
have, however, often been asked why does the validator complain about 
X and my only answer was probably it's over-eager... AGAIN.


So maybe you have taken off a lot of it's edge in the last months (and 
you are right, I haven't followed recent developments, I wasn't even 
aware that you were actively developing validator code), and maybe these 
situations have been fixed meanwhile, but certainly more than once in 
the past I have cursed validator for giving people all the wrong ideas 
and in fact introducing a streamlined kind of mapping which has never 
been OSM style.


So before blaming all and everything 
start to get more in touch with the recent code base and when necessary 
file bug reports where fine tuning is needed.


In my eyes the validator does not have a problem with one specific 
check; it has an attitude problem. Until now I wasn't aware that it was 
*your* attitude I was criticizing when I said so ;) but I think the 
validator is nannying people too much, *especially* (and I checked that 
before writing it) since it is enabled by default on a new install.


I don't even have to look past the warning dialog for my first 
complaint: Even if the list contains only warnings, the dialog title 
still reads: Data has errors. - That's what I mean by attitude 
problem; in my eyes it is totally wrong to *ever* tell a mapper that his 
data has errors. The validator can at most point out potential 
problems - but data has errors? As an expericed mapper I percieve that 
to be arrogance on JOSM's part, and as a newbie mapper I would certainly 
not proceed with uploading.


I'll give some examples for checks that I think are nannying too much, 
all these are active by default:


* untagged way (warning) - perfectly ok if such a way is a relation 
member. You're not showing the warning if it is a multipolygon but there 
may be others you don't know of.
* unknown relation type (warning) - JOSM should never assume to be in 
possession of a full list of allowed relation types!
* unnamed ways (warning) - I think it is perfectly normal to draw 
streets from aerial imagery and have no name for them.
* illegal tag/value combinations - someone seems to have had a field 
day here. 90% of these deserve to be thrown out. Only recently it 
complained about my man_made=pipeline - from reading the source I 
found out that it was expecting an extra tag with details about the 
pipeline.


To understand the severity of this, take this example: You are new to 
JOSM. You map a road and tag it highway=road. You hit upload. You get 
(emphasis by me):


Data WITH ERRORS. Upload anyway?
+ Warnings
  + ILLEGAL tag/value combinations - temporary highway type

So, highway=road is an error, and an illegal combination of a tag and 
value? Thankfully it doesn't complain when I write highway=raod. Maybe I 
should use highway=raod instead of highway=road as the latter is clearly 
illegal and an error.


I think the main problem is that the validator is now by default enabled 
before download - something you can switch off, of course, but to the 
new mapper the Your data has errors message conveys: We don't want 
your data, please stop what you're doing!


It is funny that both of us seem to have a desire to nanny JOSM users, 
just whenever you're doing it I complain and vice versa.


Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09 E008°23'33

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


[josm-dev] validator and ignoretags.cfg

2010-12-17 Thread Gleb Smirnoff
  Hello!

  I'm trying to understand the logic of the T: prefixed
entries in the ignoretags.cfg. They aren't documented.

It looks like the checkPrimitive() method of TagChecker class
implies that if any of the tags under T: present, then
the other one should be there too. And if not it treats that
as error (not warning, not info). Is this desired behavior?

For example, default ignoretags.cfg implies that man_made=pipeline
can't exist without additional tags. Is this correct?

-- 
Totus tuus, Glebius.

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] validator warning for touching inner multipolygon-ways

2010-08-23 Thread Lennard

On 23-8-2010 11:38, M∡rtin Koppenhoefer wrote:

Frederik pointed out in a recent discussion (sorry for not quoting
precisely) that OSM generally supports/encourages touching inner ways
of multipolygons (which I think is a good idea because it happens all
them time, and saves us lots of double ways).

My point now: JOSM validator gives a warning on those. Could we get
rid of this warning?


Not only touching inner ways. The validator will generally 'warn' about 
any area 'overlapping' another area, when in reality they are only 
touching along part of the way. It makes this warning generally useless.


--
Lennard


___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


[josm-dev] Validator: Unordered coastline

2009-11-03 Thread Matthias Julius
Validator just gave me an Unordered coastline error and highlighting
the last node for a coastline I had been working on.  What does that
mean?

The notion of unordered ways made sense when we still had segments.
But how can a simple list of nodes be unordered?

This error is not listed on
http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Validator#Validations
Is there another source of information about validator checks besides
Read the Source, Luke!?

Matthias

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator: Unordered coastline

2009-11-03 Thread Teemu Koskinen
On Tue, 03 Nov 2009 17:34:47 +0200, Dave Hansen d...@sr71.net wrote:

 On Tue, 2009-11-03 at 10:24 -0500, Matthias Julius wrote:
 Validator just gave me an Unordered coastline error and highlighting
 the last node for a coastline I had been working on.  What does that
 mean?

 You probably just need to turn on the drawing of direction arrows in
 your preferences.  I think that one means that you have two ways that
 are pointing in opposite directions:

   -


Yes, or more generally, the last node is not connected to first node of  
another coastline-way.
Maybe it should be called something else than unordered coastline, any  
suggestions?


Teemu Koskinen

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator: Unordered coastline

2009-11-03 Thread Matthias Julius
Matthias Julius li...@julius-net.net writes:

 Validator just gave me an Unordered coastline error and highlighting
 the last node for a coastline I had been working on.  What does that
 mean?

 The notion of unordered ways made sense when we still had segments.
 But how can a simple list of nodes be unordered?

 This error is not listed on
 http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Validator#Validations
 Is there another source of information about validator checks besides
 Read the Source, Luke!?

Actually, I just did that.  And it seems like this error is shown when
either the first node of the way is not the last node of the privious
way or the last node is not the first node of the next way.

I'll include that on the wiki.

Now, looking at my data I don't see why this error comes up.  The node
in question only belongs to the two coastline ways and it is the first
and last node respectively.

Next, I have uploaded my data to give everybody the chance to look at
it and the error is gone :-/

Now I am completely mystified.  Uploading of the 'buggy' data has
fixed it.

Could it be that backreferenceDataSet.getParents() returns deleted
ways?

Matthias

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


[josm-dev] Validator: Node near landuse - no warning

2009-02-08 Thread Henrik Niehaus
Hi,

I have noticed that the validator shows warnings, if an endnode of a way
is near a landuse way, which is ok in most cases. For example:
http://img140.imageshack.us/my.php?image=waynearlandusewn5.png (white
area is landuse=residential, way is highway=residential).

So I patched UnconnectedWays.java to ignore such cases (landuse, leisure
and building. Maybe there are more cases, which I forgot). Maybe one
could also use way.osClosed() ?!?

What do you think about this patch?

Regards
Henrik


dont_include_areas.diff.gz
Description: application/gzip
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator bug when fixing duplicate nodes

2008-12-09 Thread Pieren
Since I did start digging in the Validator code last week for the
Lambert projection issue, I can have a look on that as well.
Just tell me two things:
- is anybody allowed to assign a Josm Trac ticket to himself or anybody else ?
- what about merge conflicts ?

I could also have a look on another issue I noticed when I tried to
quickly test the Ignore feature which tried to save the information
into an inexisting file, thus raising an exception.

Pieren

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator bug when fixing duplicate nodes

2008-12-09 Thread Dirk Stöcker
On Tue, 9 Dec 2008, Pieren wrote:

 Since I did start digging in the Validator code last week for the
 Lambert projection issue, I can have a look on that as well.
 Just tell me two things:
 - is anybody allowed to assign a Josm Trac ticket to himself or anybody else ?

Yes.

 - what about merge conflicts ?

Which merge conflicts?

In SVN? Here always the one having the conflicts has to solve them :-)

 I could also have a look on another issue I noticed when I tried to
 quickly test the Ignore feature which tried to save the information
 into an inexisting file, thus raising an exception.

The FileWriter should create the file. An exception and thus a stack 
trace should only occur when for some reasons saving is not possible (e.g. 
missing permissions).

Ciao
-- 
http://www.dstoecker.eu/ (PGP key available)

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator bug when fixing duplicate nodes

2008-12-09 Thread Stephan
Pieren wrote:
 No, I talk about merging two nodes. What happens if two nodes carry
 the same key but different values. I guess the standard merge is
 prompting the conflict and expects manual decision (I don't use Josm
 here so I cannot test right now). So if we use the same action on 500
 duplicated nodes, it is possible that for some of them we have a merge
 conflict, thus a prompt.

wouldn't that be a much smarter way of handling the situation than the 
currently implemented way of simply deleting one of them?


Stephan

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator bug when fixing duplicate nodes

2008-12-08 Thread Stephan
Dirk Stöcker wrote:
 I only read the bug till now, but the solution probably is to call the 
 JOSM merge function instead of Validators own routine in case of duplicate 
 nodes.

I also would have guessed that a merge is the correct way of solving 
duplicate nodes.
What was the rationale why the validator implemented it's own way of 
fixing such a situation?

Stephan



___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator bug when fixing duplicate nodes

2008-12-08 Thread Dirk Stöcker

On Mon, 8 Dec 2008, Stephan wrote:


Dirk Stöcker wrote:

I only read the bug till now, but the solution probably is to call the
JOSM merge function instead of Validators own routine in case of duplicate
nodes.


I also would have guessed that a merge is the correct way of solving
duplicate nodes.
What was the rationale why the validator implemented it's own way of
fixing such a situation?


Maybe the validator was earlier?

Ciao
--
http://www.dstoecker.eu/ (PGP key available)___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


[josm-dev] Validator bug when fixing duplicate nodes

2008-12-07 Thread Frederik Ramm
Hi,

   there's a rather nasty validator bug that has caused some grief for 
people who mass-fixed duplicate nodes with it. The ticket has an .osm 
file attached that can be used to reproduce the problem:

http://josm.openstreetmap.de/ticket/1807

If anyone has the time to investigate this, that would be highly 
appreciated. (I'm not too familiar with the workings of the validator, 
I'll do it if nobody else can but it would probably be easy for someone 
who already works with the validator source.)

Bye
Frederik

-- 
Frederik Ramm  ##  eMail [EMAIL PROTECTED]  ##  N49°00'09 E008°23'33

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator plugin working differently for each projection

2008-12-04 Thread Francisco R. Santos
Hi Pieren,

2008/12/3 Pieren [EMAIL PROTECTED]


 I need some advice from the experts here to see how we could make the
 validator independant of the projection.
 For instance, I don't know if the grid detail of 1 was originally
 fixed for EPSG:4326 or Mercator, means if the size of the list should
 be 2 or 52.
 Shall we adapt the grid details for each projection then to have a
 constant size of cells ? Or stop working with east,north ?


That grid was used so that a way didn't compare to every other downloaded
way, but only to the nearer ones, and the value of 1 was found using
heuristics (that is, testerror until most bugs were discovered while
keeping the processing time reasonable).

I'm afraid I didn't understand very well all the implications of projections
(well, I still don't fully understand) and even Lambert projection wasn't
included in JOSM at that time, but maybe it could use different values for
different projections.

Quico
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


[josm-dev] Validator: How to find out what errors belong to a highlighted way

2008-10-28 Thread Jan Peter Stotz
Hi,

JOSM and validator users. I just updated the validator plugin which now
contains a new IMHO very useful feature: 

A filter mode which only shows those errors that a referring to the
currently selected way(s) or node(s).
By default this new feature is disabled because I didn't have a good idea
how to integrate it into the validator gui. For enabling it you have to set
the property validator.selectionFilter=true (advanced preferences - works
without restart).

Once you performed a validation and the dialogs shows some errors select
one of the validator-highlighted ways or nodes and you will see that the
number of displayed errors will be filtered to only those related to the
selected primitive are visible.

Jan


___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator

2008-08-20 Thread Dermot McNally
2008/8/20 Gervase Markham [EMAIL PROTECTED]:

 I think that both waterways and roads are layer 0, the ground, and
 when one crosses another, the upper one should have layer=1 - because
 there's air between it and the actual surface of the earth. I would
 apply this to any ground-based physical features, not just roads and rivers.

That articulates my view pretty well. Once again, consider that
layer isn't the same as level. We don't care whether a bridge
rises up above the level of the road either side of it. The
important thing is that at the point where it crosses the river, the
road must be on a higher layer than the river. So along the length
of a way, it is acceptable (and unavoidable) to have jumps in layer
that may not reflect actual changes in elevation. Layers exist to
determine the drawing order of overlapping elements, nothing more.

Dermot

-- 
--
Iren sind menschlich

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator

2008-08-20 Thread David Earl
On 20/08/2008 10:24, Dermot McNally wrote:
 Layers exist to
 determine the drawing order of overlapping elements, nothing more.

... which rather violates the don't tag for the renderer maxim, yes?

There's a few cases where it can't be avoided, like where a bridge goes 
over another bridge in a complex intersection or by chance, as here:
http://www.openstreetmap.org/?lat=52.329752lon=-0.192132zoom=18layers=B00FTF

But for the vast majority of cases, we ought to be able to tell without 
using layers.

For example,
- a waterway always goes under a road (except when marked as an 
aqueduct) irrespective of whether a bridge is marked or not.

- a bridge always goes over anything intersecting with it (other than 
possibly another bridge).

- a pond should always render on top of a park (indeed any area enclosed 
in another area could generally be assumed to render on top: even 
special cases like underground reservoirs still need to be rendered on 
top even if they are beneath a surrounding landuse area, say).

- linear ways (should) always render on top of areas, irrespective of 
any layering, POIs above those and all text on top.

David

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator - layer for waterway

2008-08-20 Thread Dirk Stöcker
On Wed, 20 Aug 2008, Bodo Meissner wrote:

 I tried this once. After having added layer=-1 to the stream the it was
 partially no longer visible on the rendered map.
 Probably there were additional problems like the river not sharing the
 nodes of the forest or overlapping forest polygon and waterway but I did
 not want to fix/change the whole stream and/or forest because I simply
 added a street crossing the stream.

I removed that check from the file.

 | As the first
 | produces many unwanted conflicts, when the bridges have been forgotten
 | (and usually many bridges are missing), this test is there.

 I think it would be better for the quality of the data if the validator
 encourages to add a bridge tag and think about the relative layers at
 this place than adding a general layer=-1 which may hide warnings about
 missing bridges.

The validator has another warning about crossing ways. This already warns 
in case ways with same layer cross outside of nodes.

Ciao
-- 
http://www.dstoecker.eu/ (PGP key available)

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator

2008-08-17 Thread Pierre-André Jacquod
Hi,
just to mention
 have selected. In any case, some violations are things that you care
 about (like missing refs) but can't always do anything about. (like
 tertiaries, where it can be difficult to determine the correct ref).
 
 Not in Germany. Here it is easy :-)

But by me (Switzerland) none of tertiary road has a ref, at least 
absolutely no reference the public is aware of / is able to see. :-( So 
for me the validator fill up all tertiary with the no-ref, but even if I 
want, I am unable to avoid this error...

  I haven't yet worked out the full scope of the ignore option - but it
  doesn't seem to ignore all similar cases, only the specific object I
 
 Correct.

which is not so a good solution in my opinion?
Thanks for JOSM, great stuff.

Pierre-André


___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator

2008-08-17 Thread Dirk Stöcker

On Sun, 17 Aug 2008, Pierre-André Jacquod wrote:


have selected. In any case, some violations are things that you care
about (like missing refs) but can't always do anything about. (like
tertiaries, where it can be difficult to determine the correct ref).


Not in Germany. Here it is easy :-)


But by me (Switzerland) none of tertiary road has a ref, at least
absolutely no reference the public is aware of / is able to see. :-( So
for me the validator fill up all tertiary with the no-ref, but even if I
want, I am unable to avoid this error...

 I haven't yet worked out the full scope of the ignore option - but it
 doesn't seem to ignore all similar cases, only the specific object I

Correct.

which is not so a good solution in my opinion?
Thanks for JOSM, great stuff.


What you can do in any case:

Instead of using the default file, copy it to your local harddisk and 
modify it. Then enter that file into the config and disable the default 
file (update validator to do so, there was an error in last version, 
which prevented using additional files).


Probably I could add a dialog in configuration, where individual rules 
can be disabled. I think about it.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator

2008-08-16 Thread Dirk Stöcker
On Sat, 16 Aug 2008, Dermot McNally wrote:

 Basically, the config file as it currently stands knows that nodes
 tagged with highway types are bad and it knows that certain classes of
 highway way that lack a ref attribute _may_ be bad. The drawback of
 the current validator as implemented is that only the message Illegal
 tag/value combinations is given. So in my case, before I read the
 config file, I looked at a highway tagged only highway=tertiary and
 had no way of knowing that the actual message is that a ref was
 missing.

This information is shown in the ToolTip. You get this when waiting a 
short time over the error message.

 The validator would in the event of catching such a case, add a
 validation violation of severity info with the text Highway without
 a reference instead of Illegal tag/value combinations

 What do you think? My fear is that if a change of this sort isn't
 made, once this currently small ruleset grows to 20 times its current
 size, we'll all have lots of validator violations but not know what
 we're doing wrong.

Actually this is already implemented. It's only moved to the ToolTip for 
two reasons:

a) There is so little space there in the Validator window
b) When I change the generic error message, the valdition dialog will be 
filled with lots of different message types. This makes finding certain 
types more difficult.

Ciao
-- 
http://www.dstoecker.eu/ (PGP key available)

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator

2008-08-16 Thread Dermot McNally
2008/8/16 Dirk Stöcker [EMAIL PROTECTED]:

 This information is shown in the ToolTip. You get this when waiting a
 short time over the error message.

Ah yes, so it is... It does force me to mouseover each violation,
though. For a large or detailed area, this is going to be very
impractical.

 Actually this is already implemented. It's only moved to the ToolTip for
 two reasons:

 a) There is so little space there in the Validator window

True - but to me, the existing top-level message isn't actually
useful, and could easily be replaced with the more specific message.
Furthermore, if I decide (as I am likely to) that it will be generally
acceptable for tertiary roads in my area not to have ref attributes, I
would value the ability to collapse and ignore a whole set of
violations. As it is, I'm going to have to search through a list of
acceptable violations to find the ones I really care about.

 b) When I change the generic error message, the valdition dialog will be
 filled with lots of different message types. This makes finding certain
 types more difficult.

Which types? As far as I can see, the only violations that will be
separated based on my suggestions are the ones that are already unlike
each other.

Dermot

-- 
--
Iren sind menschlich

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator

2008-08-16 Thread Dirk Stöcker
On Sat, 16 Aug 2008, Dermot McNally wrote:

 This information is shown in the ToolTip. You get this when waiting a
 short time over the error message.

 Ah yes, so it is... It does force me to mouseover each violation,
 though. For a large or detailed area, this is going to be very
 impractical.

Suggestions welcome.

 Actually this is already implemented. It's only moved to the ToolTip for
 two reasons:

 a) There is so little space there in the Validator window

 True - but to me, the existing top-level message isn't actually
 useful, and could easily be replaced with the more specific message.
 Furthermore, if I decide (as I am likely to) that it will be generally
 acceptable for tertiary roads in my area not to have ref attributes, I
 would value the ability to collapse and ignore a whole set of
 violations. As it is, I'm going to have to search through a list of
 acceptable violations to find the ones I really care about.

You can ignore them once and for all the time :-)

Don't know how make an ignore for specific tests in the test-set. But it's 
a new feature. Give it some time to mature.

 b) When I change the generic error message, the valdition dialog will be
 filled with lots of different message types. This makes finding certain
 types more difficult.

 Which types? As far as I can see, the only violations that will be
 separated based on my suggestions are the ones that are already unlike
 each other.

Yes. The other validation types. Think of e.g. 30 different TagChecker 
types and one unclosed way. You wont find it in this batch of TagChecker 
stuff.

Ciao
-- 
http://www.dstoecker.eu/ (PGP key available)

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator

2008-08-16 Thread Dermot McNally
2008/8/16 Dirk Stöcker [EMAIL PROTECTED]:

 Ah yes, so it is... It does force me to mouseover each violation,
 though. For a large or detailed area, this is going to be very
 impractical.

 Suggestions welcome.

I'd still favour my original suggestion - rather than group all of
these new errors under the single label they now occupy, group them
instead under their respective, detailed, labels. That keeps un-reffed
road errors away from, say, typoed landuse errors. But ultimately,
what I'm saying is lose the tool tip, at least for information like
this. A good rule of thumb here, would be that tool tips are good for
followup information that might not be necessary in all cases, or for
inexperienced users. But you shouldn't put data behind a tool-tip that
is necessary in order to make use of the error message.

 You can ignore them once and for all the time :-)

I haven't yet worked out the full scope of the ignore option - but it
doesn't seem to ignore all similar cases, only the specific object I
have selected. In any case, some violations are things that you care
about (like missing refs) but can't always do anything about. (like
tertiaries, where it can be difficult to determine the correct ref).

 Don't know how make an ignore for specific tests in the test-set. But it's
 a new feature. Give it some time to mature.

For sure. Lest there should be any doubt, I really like what you've
done here. I'm just struggling with aspects of how the results are
output.

 Yes. The other validation types. Think of e.g. 30 different TagChecker
 types and one unclosed way. You wont find it in this batch of TagChecker
 stuff.

I'm not sure I see what you mean here. It doesn't matter to the user
if a crossing way or unclosed area message isn't generated by the tag
checker, even if another 30 messages are. Each violation message
represents something that the mapper needs to review and either repair
or accept in its current state. Do we really need to contain the
tagchecker messages behind an overall label? Maybe there's a technical
reason, but it feels unnecessary from a UI perspective.

Dermot

-- 
--
Iren sind menschlich

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator

2008-08-16 Thread Dirk Stöcker
On Sat, 16 Aug 2008, Dermot McNally wrote:

 I'd still favour my original suggestion - rather than group all of
 these new errors under the single label they now occupy, group them
 instead under their respective, detailed, labels. That keeps un-reffed
 road errors away from, say, typoed landuse errors. But ultimately,
 what I'm saying is lose the tool tip, at least for information like
 this. A good rule of thumb here, would be that tool tips are good for
 followup information that might not be necessary in all cases, or for
 inexperienced users. But you shouldn't put data behind a tool-tip that
 is necessary in order to make use of the error message.

Hmm, maybe I add a third level. I think about it.

 You can ignore them once and for all the time :-)

 I haven't yet worked out the full scope of the ignore option - but it
 doesn't seem to ignore all similar cases, only the specific object I

Correct.

 have selected. In any case, some violations are things that you care
 about (like missing refs) but can't always do anything about. (like
 tertiaries, where it can be difficult to determine the correct ref).

Not in Germany. Here it is easy :-)

 Don't know how make an ignore for specific tests in the test-set. But it's
 a new feature. Give it some time to mature.

 For sure. Lest there should be any doubt, I really like what you've
 done here. I'm just struggling with aspects of how the results are
 output.

This was expectable. One of the problems is, that enabling individual 
tests is not possible.

 I'm not sure I see what you mean here. It doesn't matter to the user
 if a crossing way or unclosed area message isn't generated by the tag
 checker, even if another 30 messages are. Each violation message
 represents something that the mapper needs to review and either repair
 or accept in its current state. Do we really need to contain the
 tagchecker messages behind an overall label? Maybe there's a technical
 reason, but it feels unnecessary from a UI perspective.

On my screen I usually have 2-5 lines for the TagChecker. Yes - it is 
important to have not too many toplevel entries.

Ok, I will buy a new laptop soon, but that's no argument.

Ciao
-- 
http://www.dstoecker.eu/ (PGP key available)

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Validator patch for overlapping ways

2008-05-22 Thread Roy Rankin
Someone asked on trac if this patch 
http://josm.openstreetmap.de/ticket/774 fixes the tickets
http://josm.openstreetmap.de/ticket/726 and
http://josm.openstreetmap.de/ticket/725.

Here is my response.

This patch directly addresses the issue raised in #726. Also it deals 
with the issue raised by #725. But rather than disabling overlapping 
area ways , separates out cases where at least two of the overlapping 
ways are highways or railways. (note that two or more highways and zero 
or more other types of ways with overlapping way segments are still 
classified as overlapping highways in this patch)

Regards,
Roy Rankin
 On Wed, 2008-05-21 at 20:34 +1000, Roy Rankin wrote:
 I have submitted a patch to TRAC, ticket 774. The following is from
 the 
 report:

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev


Re: [josm-dev] Validator patch for overlapping ways

2008-05-21 Thread Dave Hansen
On Wed, 2008-05-21 at 20:34 +1000, Roy Rankin wrote:
 I have submitted a patch to TRAC, ticket 774. The following is from
 the 
 report:

Could you post here, too?

I've been doing some hacking on it as well, to the same end.  I also
added the ability to fix a small class of these overlapping ways in an
automated fashion.

If you post your patch, I'll give it a shot the next time I bring up
JOSM.  We really need to get this stuff integrated.

--- OverlappingWays.java(revision 7656)
+++ OverlappingWays.java(working copy)
@@ -2,10 +2,11 @@
 
 import static org.openstreetmap.josm.tools.I18n.tr;
 
+import java.util.ArrayList;
+import java.util.Collection;
 import java.util.List;
-import java.util.ArrayList;
 
-import org.openstreetmap.josm.data.coor.LatLon;
+import org.openstreetmap.josm.command.*;
 import org.openstreetmap.josm.data.osm.OsmPrimitive;
 import org.openstreetmap.josm.data.osm.Way;
 import org.openstreetmap.josm.data.osm.WaySegment;
@@ -44,36 +45,124 @@
nodePairs = new BagPairNode,Node, WaySegment(1000);
}
 
+@Override
+public Command fixError(TestError testError)
+{
+   Way w1 = (Way)testError.getPrimitives().get(0); 
+   Way w2 = (Way)testError.getPrimitives().get(1); 
+
+   CollectionOsmPrimitive primitives = new 
ArrayListOsmPrimitive();;
+   // we want to delete the smaller one
+   if (w1.nodes.size() = w2.nodes.size())
+   primitives.add(w2);
+   else
+   primitives.add(w1);
+
+ListCommand cmds = new ArrayListCommand();
+cmds.add(new DeleteCommand(primitives));
+   return new SequenceCommand(tr(Delete Ways), cmds);
+}
+
+   public boolean isSubWay(Way little, Way big)
+   {
+   if (little.nodes.size()  big.nodes.size()) {
+   //System.out.println(can not be subway, littlebig);
+   return false;
+   }
+   /*
+   for ( Node n : little.nodes )
+   System.out.println(little node:  + (n == 
little.nodes.get(0)));
+   for ( Node n : big.nodes )
+   System.out.println(big node:  + (n == 
big.nodes.get(0)));
+   
+   System.out.println(little.nodes.size():  + 
little.nodes.size());
+   System.out.println(big.nodes.size():  + big.nodes.size());
+   */
+   ArrayListPairNode,Node little_pairs = 
little.getNodePairs(true);
+   ArrayListPairNode,Node big_pairs = big.getNodePairs(true);
+
+   PairNode,Node first_little_pair = little_pairs.get(0);
+   int start_at = big_pairs.indexOf(first_little_pair);
+   if (start_at == -1) {
+   System.out.println(can not be subway, no index for 
flp);
+   return false;
+   }
+   PairNode,Node last_little_pair = 
little_pairs.get(little_pairs.size()-1);
+   int end_at = big_pairs.indexOf(last_little_pair);
+   if (end_at == -1) {
+   System.out.println(can not be subway, no index for 
llp);
+   return false;
+   }
+   if (start_at  end_at) {
+   int tmp = start_at;
+   start_at = end_at;
+   end_at = tmp;
+   }
+   // subList's second argument is exlcusive, so +1
+   end_at++;
+   //System.out.println(start_at:  + start_at);
+   //System.out.println(end_at:  + end_at);
+   ListPairNode,Node big_sub_list = 
big_pairs.subList(start_at, end_at);
+   //System.out.println(big_sub_list size:  + 
big_sub_list.size());
+   //System.out.println(little_pairs size:  + 
little_pairs.size());
+
+   int last_index = 0;
+   for (PairNode,Node pair : little_pairs) {
+   if (big_sub_list.indexOf(pair) != last_index) {
+   System.out.println(can not be subway, 
non-sequential pairs at:  +
+   last_index +  
but found at:  +
+   
big_sub_list.indexOf(pair));
+   return false;
+   }
+   last_index++;
+   }
+   if (last_index  little_pairs.size()) {
+   System.out.println(can not be subway, not 
right length:  + last_index +  vs.  + little_pairs.size());
+   return false;
+   }
+   return true;
+   }
+
+@Override
+public boolean isFixable(TestError testError)
+{
+   Way w1 = (Way)testError.getPrimitives().get(0);
+   Way 

Re: [josm-dev] Validator patch for overlapping ways

2008-05-21 Thread Roy Rankin

Dave,

I am not confidant I can send the patch without it being altered by my 
mailer, so here as an attachment which will not be seen by the list.

Can you not get it from the TRAC ticket?

A quick look at your patch suggests to me that not all conflicting way 
segments will show in the validation layer.


Regards,
Roy Rankin

Dave Hansen wrote:

On Wed, 2008-05-21 at 20:34 +1000, Roy Rankin wrote:

I have submitted a patch to TRAC, ticket 774. The following is from
the 
report:


Could you post here, too?

I've been doing some hacking on it as well, to the same end.  I also
added the ability to fix a small class of these overlapping ways in an
automated fashion.

If you post your patch, I'll give it a shot the next time I bring up
JOSM.  We really need to get this stuff integrated.

--- OverlappingWays.java(revision 7656)
+++ OverlappingWays.java(working copy)
@@ -2,10 +2,11 @@
 
 import static org.openstreetmap.josm.tools.I18n.tr;
 
+import java.util.ArrayList;

+import java.util.Collection;
 import java.util.List;
-import java.util.ArrayList;
 
-import org.openstreetmap.josm.data.coor.LatLon;

+import org.openstreetmap.josm.command.*;
 import org.openstreetmap.josm.data.osm.OsmPrimitive;
 import org.openstreetmap.josm.data.osm.Way;
 import org.openstreetmap.josm.data.osm.WaySegment;
@@ -44,36 +45,124 @@
nodePairs = new BagPairNode,Node, WaySegment(1000);
}
 
+@Override

+public Command fixError(TestError testError)
+{
+		Way w1 = (Way)testError.getPrimitives().get(0); 
+		Way w2 = (Way)testError.getPrimitives().get(1); 
+
+		CollectionOsmPrimitive primitives = new ArrayListOsmPrimitive();;

+   // we want to delete the smaller one
+   if (w1.nodes.size() = w2.nodes.size())
+   primitives.add(w2);
+   else
+   primitives.add(w1);
+
+ListCommand cmds = new ArrayListCommand();
+cmds.add(new DeleteCommand(primitives));
+   return new SequenceCommand(tr(Delete Ways), cmds);
+}
+
+   public boolean isSubWay(Way little, Way big)
+   {
+   if (little.nodes.size()  big.nodes.size()) {
+   //System.out.println(can not be subway, littlebig);
+   return false;
+   }
+   /*
+   for ( Node n : little.nodes )
+   System.out.println(little node:  + (n == 
little.nodes.get(0)));
+   for ( Node n : big.nodes )
+   System.out.println(big node:  + (n == 
big.nodes.get(0)));
+   
+   System.out.println(little.nodes.size():  + 
little.nodes.size());
+   System.out.println(big.nodes.size():  + big.nodes.size());
+   */
+   ArrayListPairNode,Node little_pairs = 
little.getNodePairs(true);
+   ArrayListPairNode,Node big_pairs = big.getNodePairs(true);
+
+   PairNode,Node first_little_pair = little_pairs.get(0);
+   int start_at = big_pairs.indexOf(first_little_pair);
+   if (start_at == -1) {
+   System.out.println(can not be subway, no index for 
flp);
+   return false;
+   }
+   PairNode,Node last_little_pair = 
little_pairs.get(little_pairs.size()-1);
+   int end_at = big_pairs.indexOf(last_little_pair);
+   if (end_at == -1) {
+   System.out.println(can not be subway, no index for 
llp);
+   return false;
+   }
+   if (start_at  end_at) {
+   int tmp = start_at;
+   start_at = end_at;
+   end_at = tmp;
+   }
+   // subList's second argument is exlcusive, so +1
+   end_at++;
+   //System.out.println(start_at:  + start_at);
+   //System.out.println(end_at:  + end_at);
+   ListPairNode,Node big_sub_list = 
big_pairs.subList(start_at, end_at);
+   //System.out.println(big_sub_list size:  + 
big_sub_list.size());
+   //System.out.println(little_pairs size:  + 
little_pairs.size());
+
+   int last_index = 0;
+   for (PairNode,Node pair : little_pairs) {
+   if (big_sub_list.indexOf(pair) != last_index) {
+   System.out.println(can not be subway, 
non-sequential pairs at:  +
+   last_index +  but 
found at:  +
+   
big_sub_list.indexOf(pair));
+   return false;
+   }
+   last_index++;
+   }
+   if (last_index  little_pairs.size()) {
+   System.out.println(can not be subway, not right 

Re: [josm-dev] Validator patch for overlapping ways

2008-05-21 Thread Dave Hansen

On Thu, 2008-05-22 at 07:11 +1000, Roy Rankin wrote:
 
 
 A quick look at your patch suggests to me that not all conflicting
 way 
 segments will show in the validation layer.

I don't doubt you, but care to elaborate? ;)

-- Dave


___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev


Re: [josm-dev] Validator plugin WronglyOrderedWays false error

2008-05-12 Thread Karl Newman
On Sun, May 11, 2008 at 4:50 AM, Roy Rankin [EMAIL PROTECTED] wrote:

 Thanks Martijn. I have convinced myself your tip is the correct approach
  (although your formula is slightly wrong as it gives twice the area)
 and I have replaced my changes with a new fix using this new approach in
 the 737 trac ticket.

 Regards,
 Roy Rankin

 Martijn van Oosterhout wrote:
  On Sun, May 11, 2008 at 9:58 AM, Roy Rankin [EMAIL PROTECTED] wrote:
  I have done a rewrite of the code as follows:
 
   Determine the mean latitude of the closed way.
   Then add the deltas of longitude for each segment starting with
   a latitude greater than mean and subtract the deltas of longitude
   if the start is less than the mean latitude.
 
   The result should be positive for clockwise ways and negative
   for counter-clockwise ways.
 
  You're almost there. You should just use the proper formula for the
  area of a polygon:
 
  for each node
area += x*deltay - y*deltax
 
  Dont' need to calculte the mean, nor test anything for direction. And
  100% relaible (for non-self-intersecting polygons anyway).
 
  Have a nice day,


The actual value of the area doesn't matter. It only matters whether the sum
is positive or negative.

Karl
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev


[josm-dev] Validator plugin WronglyOrderedWays false error

2008-05-11 Thread Roy Rankin
The validator plugin was giving a false error on a lake with a clockwise 
way. When I looked at the code, I found the code locates the most 
northern point of the way and then looks at the next point and if it is 
east of the north point the way is considered to be clockwise. In my 
case the northern point of the clockwise way was also the most eastern 
point so it considered the way counter-clockwise.


I have done a rewrite of the code as follows:

 Determine the mean latitude of the closed way.
 Then add the deltas of longitude for each segment starting with
 a latitude greater than mean and subtract the deltas of longitude
 if the start is less than the mean latitude.

  The result should be positive for clockwise ways and negative
  for counter-clockwise ways.

This may still incorrectly determine the direction of the way in some 
cases, but should be much more reliable then before.


I also noticed the validation error result labels were not correct and 
fixed this error.


Attached are my changes.

Regards,
Roy Rankin
  *


___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev


Re: [josm-dev] Validator plugin WronglyOrderedWays false error

2008-05-11 Thread Martijn van Oosterhout
On Sun, May 11, 2008 at 9:58 AM, Roy Rankin [EMAIL PROTECTED] wrote:
 I have done a rewrite of the code as follows:

  Determine the mean latitude of the closed way.
  Then add the deltas of longitude for each segment starting with
  a latitude greater than mean and subtract the deltas of longitude
  if the start is less than the mean latitude.

  The result should be positive for clockwise ways and negative
  for counter-clockwise ways.

You're almost there. You should just use the proper formula for the
area of a polygon:

for each node
  area += x*deltay - y*deltax

Dont' need to calculte the mean, nor test anything for direction. And
100% relaible (for non-self-intersecting polygons anyway).

Have a nice day,
-- 
Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev


Re: [josm-dev] Validator plugin WronglyOrderedWays false error

2008-05-11 Thread Roy Rankin
Thanks Martijn. I have convinced myself your tip is the correct approach 
  (although your formula is slightly wrong as it gives twice the area) 
and I have replaced my changes with a new fix using this new approach in 
the 737 trac ticket.

Regards,
Roy Rankin

Martijn van Oosterhout wrote:
 On Sun, May 11, 2008 at 9:58 AM, Roy Rankin [EMAIL PROTECTED] wrote:
 I have done a rewrite of the code as follows:

  Determine the mean latitude of the closed way.
  Then add the deltas of longitude for each segment starting with
  a latitude greater than mean and subtract the deltas of longitude
  if the start is less than the mean latitude.

  The result should be positive for clockwise ways and negative
  for counter-clockwise ways.
 
 You're almost there. You should just use the proper formula for the
 area of a polygon:
 
 for each node
   area += x*deltay - y*deltax
 
 Dont' need to calculte the mean, nor test anything for direction. And
 100% relaible (for non-self-intersecting polygons anyway).
 
 Have a nice day,

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev