Opened 14 years ago

Closed 14 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 by ajoessen, 14 years ago

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 by bastiK, 14 years ago

Resolution: fixed
Status: newclosed

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

comment:3 by stoecker, 14 years ago

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 by bastiK, 14 years ago

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

comment:5 by stoecker, 14 years ago

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 by bastiK, 14 years ago

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

comment:7 by bastiK, 14 years ago

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 by bastiK, 14 years ago

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 by anonymous, 14 years ago

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

comment:10 by stoecker, 14 years ago

Last was me :-)

comment:11 by bastiK, 14 years ago

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

comment:12 by stoecker, 14 years ago

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 by bastiK, 14 years ago

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

comment:14 by stoecker, 14 years ago

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. Next status will be 'reopened'.

Add Comment

E-mail address and name can be saved in the Preferences .
Note: See TracTickets for help on using tickets.