alidiepuit / osmtracker-android

Automatically exported from code.google.com/p/osmtracker-android
GNU General Public License v3.0
0 stars 0 forks source link

Amenity tags show up as "Name", don't follow OSM convention #55

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
All tags I get when I edit (with Potlatch) a track generated by OSMtracker that 
include POIs are "Name" instead of "amenity" and the property is upper case (ie 
"Post Box").

This should be "amenit: post_box". All amenity tags I have tried have this 
problem, meaning I then have to edit each POI individually and correct it for 
it to be useful.

Original issue reported on code.google.com by magic...@gmail.com on 19 Aug 2010 at 4:11

GoogleCodeExporter commented 9 years ago
I believe this is more general. It would be nice if when pressing a button, the 
POI that gets saved respects the conventions laid out in the Map Features wiki 
page [1]. That way you wouldn't have to modify by hand all the POIs of a track, 
as explained by magicfab.

[1] http://wiki.openstreetmap.org/wiki/Map_Features

Original comment by emilien.klein on 24 Sep 2010 at 8:53

GoogleCodeExporter commented 9 years ago
I guess it makes sense. If some is brave enough to "translate" the actual 
layout file to OSM-compliant tags I'd be glad to include it :-) See the 
Translate wiki page for more info.

Original comment by nguillau...@gmail.com on 24 Sep 2010 at 9:23

GoogleCodeExporter commented 9 years ago
IMHO we should add an additional attribute with that information to the button 
tag like

<button type="tag" label="Post box" value="amenity: post_box" 
icon="button_misc_post_box" />

so that the label is different from that beeing recorded.

Original comment by matthias...@gmail.com on 24 Sep 2010 at 9:42

GoogleCodeExporter commented 9 years ago
The thing is that the buttons are fine. It's the actual data that gets saved 
that is not.

Example:
You click on the "Post box" button. It will generate this POI: 

ele: <number>
name: Post box

The name is the actual label of the button (I see that because my values are in 
French). Once uploaded to OSM, those don't make sense as is and need to be 
translated to a "OSM-compliant" tag. In this case we would have:

ele: <number> (if you want to keep that info)
amenity: post_box

Mathias just sent an update, son I'm not continuing this post, because he 
sumarizes it very well ;) Adding a new attribute with what's going to be saved 
seems to be the way to go.

Original comment by emilien.klein on 24 Sep 2010 at 9:45

GoogleCodeExporter commented 9 years ago
Hm ok, forgot that labels are also used as button labels ! It's friday night 
here, sorry... ;)

Adding a new attribute is definitively the solution.

Original comment by nguillau...@gmail.com on 24 Sep 2010 at 9:56

GoogleCodeExporter commented 9 years ago
This new attribute will do the trick for points, but not for ways or areas 
(like landuse or type of highway). So I think we need to support both systems:

- If a button has a "value" attribute, use this to create the POI (fixes the 
post box issue)
- Else, continue using the current system by creating a POI with the name 
attribute containing the button label.

That way we also don't force people to update their custom layouts (but they 
could in order to create "OSM-compliant" POIs.

Does this seem to you as a good solution?

Also, we should let the value attribute contain possibly more than one tag by 
separating it with a ";". It could be necessay to have to add more than one tag 
to a POI (can't find a good example off the top of my head right now though...)

Original comment by emilien.klein on 25 Sep 2010 at 3:01

GoogleCodeExporter commented 9 years ago
P.S.: Once we agree on the way to fix this I volunteer to do it.

Original comment by emilien.klein on 25 Sep 2010 at 3:04

GoogleCodeExporter commented 9 years ago
It seems that the GPX files don't natively support adding new custom nodes, 
except if you define an extension. And then this should be supported/understood 
by OSM so that they can put the right attributes to the POIs.

I've started a discussion on the OSM dev mailing list [1] to see if there 
already is support for custom "OSM-compliant" attributes in GPX tracks. I'll 
keep you updated, but this seems more complex than just adding a new XML 
attribute in OSMTracker's layout files ;)

[1] http://lists.openstreetmap.org/pipermail/dev/2010-September/020659.html

Original comment by emilien.klein on 28 Sep 2010 at 8:13

GoogleCodeExporter commented 9 years ago
Well, i realized this message is more directed to the editor's mailing lists 
than to the general OSM dev... Anyway, I've tested opening a GPX track in JOSM, 
and the nodes are not editable, you can't even select the track or the POIs 
recorded in the GPX file. So I guess this is more directed to Potlatch, because 
there the points are accessible.

@magicfab, are you using Potlatch? Or another editor?

If you lool at the code of Potlatch [1] they are only looking at those 4 
elements to add to a POI:
- name
- ele
- sym
- desc

I am going to contact them to see if supporting a custom GPX extension would be 
a possibility.

[1] 
http://trac.openstreetmap.org/browser/applications/editors/potlatch/gps.as#L63

Original comment by emilien.klein on 29 Sep 2010 at 9:23

GoogleCodeExporter commented 9 years ago
Yep the difficulty will be to find a suitable standard for everyone. I guess 
starting to implement something, release it, and see how it goes is probably 
the usual way to do ;-)

I studied the possibility of creating an extension for GPX when adding 
precision information in the GPX file (issue #10), but I gave up and used the 
<cmt> tag as it was directly recognized by OSM editors.

In the meantime adding a "value" tag in layouts file is probably the most 
reasonable thing to do.

Original comment by nguillau...@gmail.com on 29 Sep 2010 at 12:19

GoogleCodeExporter commented 9 years ago
Before implementing it, I think we should still put the question to the 
editors' developers. I think that JOSM won't be interested, since the GPX 
waypoints can't be edited, but for Potlatch it's another story. If they are 
interested in this, maybe we can all come together on a same solution (that 
other editors could then support). But if we're the only one to do that, then 
it won't show up in any editors ;)

Also, i believe that if we add this info in a new extension (or whatever 
solution we come up with), we must not remove what's already done (i.e in the 
Name element), because all editors won't support this extension. If you open 
the GPX in JOSM and we have removed the info in the Name, then nothing will 
show up in JOSM...

Original comment by emilien.klein on 29 Sep 2010 at 12:33

GoogleCodeExporter commented 9 years ago
Perhaps we could add an additional output format for JOSM:
http://wiki.openstreetmap.org/wiki/JOSM_file_format
I'm not sure if this is the right format, but it can be edited in JOSM like a 
normal OSM data layer.

Here a list of file formats for OSM.
http://wiki.openstreetmap.org/wiki/Category:DataFormats

Original comment by matthias...@gmail.com on 29 Sep 2010 at 1:42

GoogleCodeExporter commented 9 years ago
No, the GPS export format has to be GPX [1], otherwise it can't be uploaded to 
OSM. The JOSM file format (.osm files) are used to save data from JOSM.
Also have a look at the "usage and intended use" section of the link you 
provided. This excludes Android applications pretty much ;)

[1] http://wiki.openstreetmap.org/wiki/Upload

Original comment by emilien.klein on 29 Sep 2010 at 1:59

GoogleCodeExporter commented 9 years ago
So, sent that email to potlatch-dev to see if they already have a solution, or 
if they would accept to think about one ;)

http://lists.openstreetmap.org/pipermail/potlatch-dev/2010-September/000158.html

Original comment by emilien.klein on 29 Sep 2010 at 2:34

GoogleCodeExporter commented 9 years ago
Is it new atribute "value" (from Comment #3) aviable? It will be very useful to 
have it in layout.

Original comment by vaclav.k...@gmail.com on 8 Jun 2012 at 10:10