[talk-au] Updating the validator plugin...

[John Smith]

--- On Sat, 4/7/09, Rick Peterson <ausrick at iinet.net.au> wrote:

> The 'addr:postcode' key is in the presets because
> it's the recommended
> way of entering a postcode (should you want to) when
> applying street
> numbering along a way. It doesn't really apply when
> providing a
> postcode for a suburb or group of suburbs as is the case
> with the ABS
> bulk import.

What is, if anything, used for place markers or other types of non-address specific markers?

> None of the keys developed for the ABS bulk import (or
> other special
> projects in Australia) need to be included in the presets
> menu within
> JOSM. This menu is a feature for the convenience of JOSM
> editors when
> entering commonly used keys/key combinations.

Not just Australia, the tiger data set has a bunch of other keys that would be well worth ignoring, there is probably a lot of "attribution" type keys that need to exist for legal purposes, that aren't considered "valid" but shouldn't cause warnings.

> This is where the flaw in the current plugin programming is
> revealed.

The coder probably thought he was being quite clever reusing the preset data to validate the current information.

> The preset menu is trying to be used for more than it was
> originally
> designed. The people managing this plugin may tell you that
> you'll
> always get errors, because not all keys that are validly
> used are also
> in the presets.

There is a big diff here between an actual valid warning/error/info alert and just noise, the noise should be removed so the validator plugin can be useful.

> What they don't realise is that once you start ignoring
> error warnings,
> it can quickly become a one way street and the value of the
> plugin can
> be diminished to the point where you may as well not run it
> at all... I
> mean why would you, if you ignore everything?

Well earlier this week it took me a bit to figure out why unnamed streets weren't showing and I'm not exactly a newbie when it comes to computers, so it's a perfect example to illustrate your point.


> This is a great way to address the issue!  

The tag checking should have been implemented similar to this in the first place, not saying my code style or method to solve this problem is perfect, but it does come closer than just relying on presets as the be all and end all.

> Just as external files are used by the validator plugin
> for:

I tried to code within the existing frame work so the code was more likely to make it into the trunk code.

> 2. A list appending only specially used keys to be used in
> conjunction
> with the existing presets method.

I've gone with this, the code already exists to validate against the presets so we might as well use that information, as well as building a secondary list to supplement it.

If there are any warnings still being triggers, let me know the key name or the specific key pair if the key can't equal anything and I'll include it in the list.

Which brings me back to postal_code, should this be ignored or what should we do about this specifically?