Proposal talk:Internal quality

New discussion about version 2

This new version is reduced to cover only (for now) the noname case. The question is do we keep "ignore" value or "yes" value or do we propose something else. My goal is still to end with at least one tag on wich we can start our validators to agree.

Interesting objections where raised (archives are here : Proposed features/Internal quality/old_votes )

So I reduce the number of keys to this proposal to at least solve the noname case

Some objections came from that there was too many values and that the "ignore" solution for tags should stay as the only one, or that it should be supress.

I am in favor of suppressing the idea of "ignore" here is a copy of my thinking :

Looks like we have two approach here, wich confirm to me that validate:no_name=yes and validate:no_name=ignore are duplicates. We have around half people thinking the "ignore" syntax is best, while the other half think validate:no_name=yes is best. I am scared by the fact "ignore" might be abused just to shut up a validator (well, that's also true for yes). In the end it's rather just a question of words, and doesn't look like a big deal. But what I like in the "yes" approach, is that it says it has one information (that there is no name) while the other just focus on validators. The result in the end is just the same but the method for it seams more straight forward understanding it with "yes". Well, anyhow, I suggest we drop one for now. But I still like the no_sign stuff because it makes a rather interesting little variation that someone might be interested in. Let's put that back to RFC, yet another time for thinking and talking, not voting. Sletuffe 21:07, 29 November 2008 (UTC)

Way accuracy metrics?

Does validate=* offer possible tagging of ways that are inaccurate?
I'm thinking of a case of mapping trails: Lets say that a non-GPS using hiker knows the terrain very well, and are capable of tracing paths based on available data such as existing paths and roads, elevation contours (view output from srtm2osm as a background layer in JOSM), and Landsat imagery. This is very valuable, but even more useful if it can be labeled for what it is. vibrog 22:02, 28 December 2008 (UTC)

For me yes, this tag could also be used to give some sort of "quality" scale of the way you are mapping. I planned to use it as a "gps quality" scale such as : validate:gps=bad validate:gps=no ( bad meaning the signal was very poor and lot of extrapolation was done, no mean that there was no gps track used at all). But we might be even better by taking imagery tagging into account, or even good knowlege of the terrain. For that, extensions of validate:???? have to be proposed (This is what was intended when created).

I have allready wrote down ideas of things to capture : Proposed_features/internal_informations_between_mappers#Tag, Values and Usage and Talk:Proposed_features/internal_informations_between_mappers#other possible values Sletuffe 13:18, 29 December 2008 (UTC)

This can be used by a Cleanup Taskforce similar to the cleanup message templates used by Wikipedia, and to create maps that show how the map lives up to OpenStreetMap's quality standards. vibrog 09:19, 29 December 2008 (UTC)

Discussion about version 1

Possible conflict

One question always asked about the noname proposal is : who is to trust ?

What to do/think when we have something like :

• highway=residential
• name=Hell street
• validate:noname=yes

Well, whatever the truth is, there is an error, either the internal tags shouldn't be there, either the name and oneway tags are wrong.

In this case, a mappers rendering tool should enlight that street to ask for a survey and proper action. Sletuffe 09:35, 25 November 2008 (UTC)

petschge: In this case a new test for maplint (and possible other checkers / renderers) is going to highlight that point as "self contradicting tagging". To really make this impossible we'd need help from the editors.

I forgot to sign the previous message, I've moved this section to talk page, not to polute to much the page, and yeah I think this is not "that much of a problem". A special error handling could enlight the fact that there is an "incoherence". Help from editors is however, not yet to be expected imho Sletuffe 09:35, 25 November 2008 (UTC)

Return to the basics : nonames maps were created because the vast majority of the missing names are coming from contributors creating highways from the Yahoo satellite imagery. The tag highway=road has been created for these guys, saying "I've not been on site, I cannot classify this road but feel free to adjust when you are there". The same thing happens with the name. If the way is created from Yahoo, the tag name is most probably not populated. The noname maps show that a name has to be fulfilled based on a visit on site or from any other valid source of information. If there is really no name, just create a magic keyword for those very rare cases. That's all we need. -- Pieren 11:51, 30 November 2008 (UTC)

That's what I want to do with validate:no_name=yes or validate:no_name=no_sign. Those tags should be only rarely used in the goal to say "I know that this feature really has no name" That's why I don't like too much the "ignore" logic, where people could abuse it. But the case is still true with validate:no_name=yes. My goal is just that validators tools should agree with a common way to do things so we don't end with :

• name = FIXME / name=__none__ / name=none / noname=yes too much .

I fear there might be some kind of confusion, people reading validate:no_name=yes might think it says that there are still no name to the feature, and that a name should be added. But this is absolutely not my intention. A street that has no yet a tag "name" does not need a validate:no_name=yes. It's self contain in the fact that there is no name tag. This tag is only to say that the feature really has no name, or really does not have a sign to get it's name from Sletuffe 15:30, 30 November 2008 (UTC)

Ignore values

I don't like the 'ignore' values. I don't think one should be able to say 'ignore all errors'. e.g. I don't think there's any sensible use for validate:layer=ignore. If a bridge doesn't have a layer, that is an error in the database. We need to go out and figure out it's layer and then add it to the database. One should not be able to silence errors about this tag. I think people will use this tag and other validate:T=ignore in order to just make the map report no errors, instead of going out and actually mapping things.

I agree with you, and I am not using it on my validator. But you should have vote "yes" to others and refuse any =ignore things so we can at least have something Sletuffe 12:09, 25 November 2008 (UTC)

PDOP

What about validating the quality of a GPS signal? When using raw NMEA data for tracking, it is possible to know the DOP (Dilution of Position) values. This could for instance be tagged validate:pdop=1.0. The value of validate:pdop should correspodent to the actual PDOP or an average PDOP over time used on the gps during the survey in question. A high number would indicate that the area is surveyed with GPS, but with bad signal or no correction signals, a low number would indicate a very accurate possition, and corrections should only be done with great caution. --Skippern 15:38, 7 February 2009 (UTC)

I'm okay with that, but since not every one knowns what pdop is, and not every one has access to it (garmin 60cx for instance) I would propose to add it along something more "human friendly" such as validate:gps_quality=good Sletuffe 16:05, 7 February 2009 (UTC)

I've added it to the list of "idea" : Internal_quality/Other_tags_to_vote_on_later Sletuffe 16:08, 7 February 2009 (UTC)