Opened 13 years ago

Closed 13 years ago

#5228 closed defect (fixed)

JOSM displays wrong data

Reported by: wonk Owned by: team
Priority: normal Milestone:
Component: Core Version: tested
Keywords: Cc:


Hi! I have a strange error in the OSM-Data shown by JOSM. Another user told me, it's a JOSM-error. The error occurs in the line-relation of a bus-route-relation. The bus-route-relation ist ok (No 1.021.106 for example), but the entry for the parent-relation is "Freileitung (Starkstrom)", which means a wrong name. The parent-relation is okay too(1.026.689), the wrong name is only shown in the JOSM-display. The correct name is "Bus 40".
It was not possible, to load the parent-relation of the line-relation (network "AVV").


Attachments (0)

Change History (14)

comment:1 Changed 13 years ago by ajoessen

The error is caused by the type=line tag for the relation 1026689.
This tag is according to the oxomoa-Scheme used for public transport in Germany.

For power lines, relations with a tag type=route route=power or route=power is common. So no conflict with power lines mapping, but a translation error.


comment:2 Changed 13 years ago by bastiK

Resolution: fixed
Status: newclosed

(In [3389]) fixed #5228 - type=line (bus-)relation is translated to "Freileitung (Starkstrom)" (power line)

comment:3 Changed 13 years ago by stoecker

Resolution: fixed
Status: closedreopened

Whereas the first fix is ok, the "trc("Relation type", relation.get("type"))" effectively disables the whole tranlsation, as relation types are nowhere translated explicitely.

comment:4 Changed 13 years ago by bastiK

I added it to i18n/ This should work, right?

comment:5 Changed 13 years ago by stoecker

Well, but only for hand translated messages. The idea was to use our string pool for "automatic translation". Probably best is to use context translation first and try context-less afterwards. So we use our pool, but also can add better translations for known types.

comment:6 Changed 13 years ago by bastiK

I would prefer explicit translations for each relation type, but your suggestion is acceptable.

comment:7 Changed 13 years ago by bastiK

Note that adding a type to i18n/ would not invalidate the default translation from the pool. In some languages, the "Relation type"-context translation may be available and in others not. You would have to add a context for the pool translation, as well (like I did for "line").

comment:8 Changed 13 years ago by bastiK

PPS: When a strange relation type is translated by chance, the user might get the impression, it is known to the editor, or JOSM has validated the relation and blesses it.

comment:9 Changed 13 years ago by anonymous

We could fix that, when we add translation texts for all common relation types.

comment:10 Changed 13 years ago by stoecker

Last was me :-)

comment:11 Changed 13 years ago by bastiK

Sorry, I don't really understand your message. :)

comment:12 Changed 13 years ago by stoecker

When all types are properly translated, we don't need a heuristic translation. So instead of code fixing adding missing types is also a option.

comment:13 Changed 13 years ago by bastiK

I vote for that option ;). Can we close this thread, then?

comment:14 Changed 13 years ago by stoecker

Resolution: fixed
Status: reopenedclosed

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted.

Add Comment

E-mail address and name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.