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.
See http://josm.openstreetmap.de/ticket/11414
___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev
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
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
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
-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
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,
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
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
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
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
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
--
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
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
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
-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
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,
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
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
@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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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.
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.
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
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.
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:
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
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
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.
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
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.
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 :-)
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
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.
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.
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
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
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
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
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
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
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
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
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
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
79 matches
Mail list logo
