Proposal talk:Internal informations between mappers

The wrong way around

I'm focusing on the "internal=oneway_unknown" a bit here

Suppose someone adds a new road, and tags it 'highway=primary'. Now we don't know if that person has actually made sure that the road is not oneway. So the next person comes along and adds 'internal=oneway_unknown'. A third person checks the actual road, sees that it is not oneway and deletes the 'internal=oneway_unknown'.

It will work only if tagging the road as 'oneway=no' is mandatory. But in that case, the absence of any oneway tag is enough evidence. --Phicoh 12:03, 13 October 2008 (UTC)

Two ways to deal with that : either explain that noone should add it unless it is known that it is unknown ;-) or create a internal=oneway_known. or use oneway=no ( but I don't like that oneway=no wich may already have been used for the purpose I'm describing here ) Sletuffe 13:28, 13 October 2008 (UTC)

will not be used ?

Someone might argue that people are too lazy to add this information at every street they map. Sure !. And I personnaly won't use it that much this way.

The idea comes from an ongoing suvey in Paris France, where many street were mapped with the yahoo imagery and the oneway tag has to be locally surveyed. The solution I will do there is this :

• Download in JOSM every way in Paris.
• Select all ways with no oneway tag
• Add a tag "internal=oneway_unknown"
• Go back to the noname layer
• Get my next bike destination ;-)
• Go back and correct

Sletuffe 09:36, 13 October 2008 (UTC)

FIXME=*

I'd say keep FIXME=* for more elaborate verbal definitions of what to fix, when needed. Alv 08:56, 13 October 2008 (UTC)

ok, I re-read the FIXME=* tag and I misunderstood it, I thought it was a "fixme=yes" style tag, but it's goal is to have text readable by humans, ok I remove the deprecation part Sletuffe 09:02, 13 October 2008 (UTC)

many tags with same key

Although supported by current implementation (but few if none editors), multiple occurrences of one tag for one object is (from what I've read) "possibly likely" to be dropped from API 0.6. Since the values for internal=* would be from a defined list, having them in one semicolon separated list for any object wouldn't matter. Anyone parsing the value needs to be able to drop unknown values, anyways. We can use Tagwatch to spot and fix typos. Alv 08:56, 13 October 2008 (UTC)

Argh ! the "semicolon separated list" solution is quite ugly IMHO and hard to proccess by a human ( if there are may values ) Sletuffe 09:04, 13 October 2008 (UTC)

Not that I like it, either, but for semi-automated software processing it's usable. And if I had the time even I might take a try at coding a plugin for josm for easier editing. Alv 09:29, 13 October 2008 (UTC)

If it is a defined list , then it is obviously to be machine processed then the semi-colon is not a problem ! --PhilippeP 10:03, 13 October 2008 (UTC)

Ouch, I didn't notice JOSM was not able to add multiple keys. Then ok with the "semicolon separated list", but no ! arghhh my goal was to easily mass edit a given zone to add a tag such as "internal=oneway_unknown" and then remove them as my mapping is done. this become impossible because I will drop already existing internal=* tags. F****, all this becomes a bit useless given this.

Last hope (before having to deeply correct editors) adding a internal:oneway=unknown. Or add the possibility for editors to add a value to an existing key's value. Sletuffe 11:45, 13 October 2008 (UTC)

other possible values

Here is my last thought on other possible values :

• internal=bad_gps
• internal=no_ref
• internal=not_finished
• internal=no_more_roads
• internal=max_speed_unknown
• internal=no_max_speed
• internal=missing_sideroads

Sletuffe 09:06, 13 October 2008 (UTC)

• internal=missing_sideroads when the locations and of sidestreets was not noted/drawn.

But would that be the opposite of no_more roads? Emptiness -> one short way with not_finished (the way itself continues) -> longer way (complete for its part), stubs for some sidestreets (each with not_finished) -> stubs for (verifiably) all sidestreets + internal=no_more_roads? Alv 09:37, 13 October 2008 (UTC)

Those example just dropped out of my mind and are not part of the starting proposal, because I don't know if they are clever enough. "internal=no_more_roads" seams now a bit silly, few configuration could lead to say : "ok it's finished". I would prefer your proposition saying :"there are still unmapped side streets" Sletuffe 07:49, 14 October 2008 (UTC)

Meta information to diverse to put in one tag

I agree that mechanisms to manage internal (or meta) information about the osm data are needed very much. However, I do not think that squeezing all this very diverse meta information in one tag (with a very generic name) is a good way of doing it. We should rather look at the different types of meta information that we want to add to the data and decide how these different types are expressed best.

For example, notes about things that need correcting or that need to be mapped could be added as internal=todo/fixme/bug tags but that is very restricted. There is no way for others to add comments to such a bug or todo entry and finding out when it was set by whom or who solved it always requires searching the database history. A much easier way of dealing with these things would be to keep this information in a bug tracker or a ticket system like openstreetbugs.

For the problem at hand -- telling fellow mappers that tags are intentionally missing -- a simple approach with one value or tag specifing that the absence of a tag is okay is clearly sufficient. But it will clearly not solve all problems that assessing and describing the quality of the osm data will create in the future. So, why not using a tag with a clear scope to handle the missing-tags issue?

Also, despite its generic name an "internal" tag would not contain all internal information. There is already lots of "internal" information out there: There are the note, fixme, and source tags, the history contains all the meta data about past changes and editors, and openstreetbugs hold "bug reports" and todo items.

Comment : Logics : Adding tags for non-existing thingys

I quite understand the necessity to add some means which indicate the level of liability of our tracings,

as would be the possible or probable deviance of our traces in relation to reality

(as one does in road planning, related to curvature and distance, or as does professionnal gps fixing),

but I'm not yet ready to add tags to show that some thingys do NOT exist,

else we'll scram up the data base with plenty of "no-this", "no-that".

OSM is young, it will last for generations if we keep it logically clean, and up to now I'm not yet ready to accept such fundamental changements of basic logic :

Topographs draw what IS. If they are not sure of information, they do not draw it, leave it as 'sketch-out'

knowing that future generations will fill the gaps, if necessary.

For this, osm has "highway : road" and "name : FIXME".

In my eyes, up to now osm has no need to affirm 'commercial' liability whatsoever, nor any 'ISO-quality' label, as long as we do with our gps.

Maybe I'm wrong. 'Trop long'

internal:my_own=yes concept

Suppose you'r willing to organise a mapping party on some places. This place was already mapped by yahoo or any aerial images. Then you are missing the oneway=* tags or the postal_codes=* or any other tag YOU (and any others) wants to map.

Instead of hanging around unorganized, not knowing which street is left, then you could just :

• Add a internal:my_own=yes tag to any unclassified/residential of the zone
• use a error tool to see what's left in a printable or easy to watch
• correct the feature(s) you want to
• remove that tag
• start again on some other features ;-)

Keep in mind that using a well established already existing internal:*= tag would be much better, for other people not of "your clan" to know what it is about. Or else, add a proposal on this page. Sletuffe 17:42, 11 November 2008 (UTC)