Proposal talk:Key:fixme

Discussion

This is pretty similar to my earlier proposed tbc tag Proposed_features/Edge_of_known_local_universe - User:David.earl

It could be rendered as yellow-and-black diagonal stripes, to get the "work in progress" feeling. Ivansanchez 12:03, 26 January 2007 (UTC)

I would prefer being able to use this fixme tag on any node/segment/way. I would also prefer to have something like: k="fixme", v="Please add the name of this street"; which would reduce the number of keys required from 2 to 1 compared to the above proposal and allow it to be very specific. MapLint could then be extended to allow the highlighting of nodes/segments/ways that have the fixme key. We could even have a single map that would do this in the informationfreeway. This also allows for the type of road and other properties to be added, when the road name is unknown. This also helps for the newbie when all they want to do is add a single road name. The user simply has to select the way and add the name, removing the fixme tag. Unlike at the moment where they need to add the way to the segments and then add all the properties to the way instead of just the name. Smsm1 14:31, 9 May 2007 (BST)

• This would be great and doesn't have to be shown on the main map(or most maps) at all. I'm with the k=fixme option. I can use note= but it would be so much better to differentiate so it could be searched by mappers/editors(people) and then go out and fix it. I have one example where I didn't want to bother mapping all the detail of a junction I was crossing but me/someone could go back later, the other example is a brief footpath I always pass and isn't that well known (there are gates and a small sign, from the road it looks part of private land) which is best done on foot (not cycling). - LastGrape 20:47, 24 June 2007 (BST)
• I'm also for the k="fixme" v="waht exactly has to be fixed". Combined with an additional layer you can turn on/off in the map.(Banny, 2007-09-26 18:15)
• I've been using k="fixme" myself. In particular, I like to make the end node of an incomplete way a k="fixme" v="stub". It might even be reasonable to render this so that the user gets a better idea of how incomplete the map is. Robx 08:01, 23 December 2007 (UTC)

I also like the k=fixme v=WhatNeedsFixing idea. I think, we had nobody disagree on this for more than 6 months. (We have only considerations on how it should be rendered.) So could the proposal be modified? Elrond 19:42, 8 February 2008 (UTC)

Yes, just wanted to propose that :) Doesn't even need a voting imho, since it's not forever anyway --Bkr 20:14, 3 June 2008 (UTC)

There should be a way of searching or maybe even a separate map for FIXME's so that it is easier to find things that needs fixing close to where one live. --Skippern 02:16, 8 September 2008 (UTC)

Reworked the proposal

I've rewritten the proposal to bring it in line with what appears to be current usage. Objections? Some different examples of how it's used might be nice. Robx 11:27, 14 July 2008 (UTC)

Not enough computer aware

Also I'm globaly ok with the goal of this proposal, I find it too human centric and so it cannot be used in a layer or renderer for "improvement map" ( such as the current noname layer )

I think we could stay compatible with it's usage by allowing any values, but we could also add special strings in it to trigger computer management help.

Here is my thought ( on an actual proposal very close to this one ) : Talk:Proposed_features/Noname#Going even further and yes I think we could vote on it, and add it to map features in the goal to avoid people recreating a similar one. Sletuffe 12:09, 23 September 2008 (UTC)

why not use namespacing instead? fixme=foobar, where foobar is a set of predefined string-values that are human readable and - since explicitly defined - also computer readable (--> based on a set of short values that are used as "common sense" by mappers by today, like resurvey, continuation and so on. they could even be expanded by subcategories, always using the namespacing concept: fixme:resurvey=with_gps). And then there would be a fixme:note= for a note that describes WHAT has to be done in order to fix whatever is wrong, if needed. going one step further would be adding the fixme tag as a namespace to existing tags, so a mapper can specify WHAT property/key has to be fixed. e.g. would name:fixme=resurvey imply that the location/existence of a feature is correct, but its name is wrong (e.g. misspelled or just plainly wrong), whereas a general fixme-tag would imply that the entity itself is wrong/maybe not existent/...

thus generic but explicit defined fixme-values (in terms of "only these keys are allowed" enable a computer generic approach without sacrificing informative value when namespacing is used to add a specific note to the fixme tag, which is human readable and should clearly be used to define the specific issue that required for a fixme tag. and by using namespaces in conjunction with the fixme tag you can point to a certain key that needs a fixme without having to define a never ending set of values that describe specific problems (e.g. like in the internal informations between mappers-proposal). Only one problem remains: complexity of tagging values. But this shouldn't be the model's concerns. its - in my opinion - up to the editing software to offer good usability. the OSM-model should just work in terms of offering the best solution to specific problem. and the problem we are talking about is the mess we have in the fixme tag and the resulting inability to process these values in an efficient way. the approach described is - in my opinion - a good mixture of both worlds: computer processable AND human readable without sacrificing flexibility and informational value. the only thing left to do for this approach is to define a generic and smallest possible set of obligatory values for the fixme tag (and if necessary subsets). the rest works with the existing concept used in OSM. --Marc 18:35, 23 December 2009 (UTC)

Duplicate of note=* ?

By the way, this is a duplicate of the "note" tag allready in use Sletuffe 16:36, 26 September 2008 (UTC)

IMO not quite. A note=* is some observation or knowledge worth mentioning to other mappers about what has been drawn ("this road is really straight[, please keep it such]"), a FIXME=* is a call for future mappers to verify or continue surveying something ("here was a sideroad i didn't take, maybe you could?"). Alv 20:59, 26 September 2008 (UTC)

I always tag it like this: note=FIXME: This street needs to be completed!. A fixme-tag would be ok, but not really needed... --Phobie 21:07, 5 December 2008 (UTC)

It doesn't hurt to have more information in comments, note=* is afterall meant to be information to other mappers. JOSM (or other editors) should by the way have a way to highlight note=*FIXME* as well as fixme=* --Skippern 15:18, 11 December 2008 (UTC)

The problem with note=FIXME: whatever is that it's harder to manage with a computer. The problem is also that they are often used for the same purpose (because fixme= is nowhere marked as approved, so there are countless note=FIXME (or else people should use description=* ) I've seen that, in my personnal renderer, for note and fixme I was not able to make them distinct, so I have a note&fixme renderer all in one (with two different colors, but almost the same meaning)

Anyway I'me still in favor of putting both in the annotation tag list so people know they can start using it for the true meaning they are made for Sletuffe 15:40, 11 December 2008 (UTC)

FIXME or fixme

The tagwatch doesn't show continents anymore, but all the countries with significant number of fixme's (>1000) that I found had used in about 60% of the cases the key FIXME and 40% of key: fixme. Alv 08:37, 12 September 2009 (UTC)

I confirm those figures for france 871 fixme against 1185 FIXME. That key (as described on this page : lowercase) took a long time before going into the annotations map features. So people have chosen to write it like their neighbours or upercase to shout ;-)

My personnal opinion is that the Proposed_features/Key:fixme page is older than FIXME=*, that lowercase is more inline with other osm tags, and that it isn't such a big deal if people write fixme=* or FIXME=* sletuffe 10:55, 12 September 2009 (UTC)

I don't know how reliable osmdoc is, but it counts 211 784 fixme and only 28 827 FIXME. Which is strange because the tagwatch stats for individual countries (such as Germany) seem to show a small majority for FIXME. --Tordanik 12:36, 12 September 2009 (UTC)

Looks like some import added 160 000 lower case fixmes "check import".so they're in some single country.

My opinion is, too, that it doesn't matter - the motivation for adding this section was some edits claiming to "fix typos" and only changed these to lowercase keys. Alv 13:21, 12 September 2009 (UTC)

The upper case fixme was shown in Keep right from the beginning, what probably caused the community to spell it uppercase where the tool could be used. I guess now it's fixed and shows upper case and lower case fixmes. --Lulu-Ann 22:03, 12 September 2009 (UTC)

"fixme=continue" for non-deadend but terminal nodes?

Vovkav 15:08, 21 February 2010 (UTC): Shouldn't we specify continue as a recommended (semi-standard) value for fixme tag concerning incomplete non-deadend ways?

I see fixme more as a description tag what to fix, and use full sentences. Is there any case where you need equal values for automatic statistics etc? --Lulu-Ann 21:38, 23 February 2010 (UTC)

Vovkav 00:35, 24 February 2010 (UTC): Long sentences make sense when there is something unusual, rare to fix. Continueing a way is certainly not. Specific short semistandard values in turn, will make much simplier to be categorized and aggregated by bots. (English is not my native)

Using a common value for the same type of todo tasks allows maps generated for, for example Garmin units, to display an icon on every such node. Alv 07:22, 24 February 2010 (UTC)

fixme on after specific date

Something that I recently thought about was having a tag to indicate if a fixme is something that should be adressed at a later date.

So for example: There is news about a school branch that's going to stop in my town by next school year. But for now it's still a school and there is a possibility that (because of protest against it going away) it might actually stay anyway.

So in this case, putting a fixme on it with a link to the source results in there constantly being an 'open case' on the map/qa-tools even though nothing can be done about it at the moment. Only when the next school year starts do we know if the school is really going or not.

Having a tag like fixme:by=2020-09-01 would allow me to set it and hide the fixme on the qa tools till the actual date passes. That way information even when it's only applicable later in the year, can be added to openstreetmap so we don't forget about it but without cluttering the map/qa tools. Feedback is welcome