You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.
There's a yes/no box below - yes seems to mean "try again" and no means "don't". After clicking "no" you do get a "view data" option showing the osmchange xml but that's probably not a lot of use for newbies.
Zoom in and convert the orange dot north of the road to a node and try and save it.
In this case the extra-long value is created by a Garmin GPS. There are other long value trac bugs related to merged Tiger data (3846 open and 3587 closed) but this is a different aspect of the problem.
Edits can be lost due to this problem if you've done a lot of edits prior to a save and don't know where the offending waypoint that's causing the problem actually is.
Among the possible solutions are:
Filter "extensions" from the list of tags moved from the waypoint to the node (Potlatch 1 does this) - that would solve the issue I'm seeing with Garmin data but wouldn't affect the problem if someone found another way to cause it.
Position the user in the editor to the first offending item and allow them to edit it manually (harder, and might be time consuming if lots of items have the problem).
The text was updated successfully, but these errors were encountered:
Author: stevage [Added to the original trac issue at 12.15pm, Sunday, 17th July 2011]
Truncate all values at 255 characters on save
Skip any objects with values containing more than 255 characters, then warn the user about the problem (so avoiding the "lose unrelated data" problem...)
Author: Richard [Added to the original trac issue at 1.11pm, Monday, 3rd October 2011]
Manually entered tag values are truncated at 255 characters anyway; this is only an issue with imported values (as in this case, from a GPX). Fixed in systemed/potlatch2@df37a02 .
Reporter: SomeoneElse
[Submitted to the original trac issue database at 6.01am, Sunday, 17th July 2011]
If an attempt is made to save a node with a value that's too long, this message is displayed:
An unexpected error occurred, probably due to a bug in Potlatch 2. Do you want to retry? (The server said: NodeTag 1364231671: v: is too long (maximum is 255 characters) ("<extensions xmlns="http://www.topografix.com/GPX/1/1\" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance\">\n <gpxx:WaypointExtension xmlns:gpxx="http://www.garmin.com/xmlschemas/GpxExtensions/v3\">\n gpxx:DisplayModeSymbolAndName</gpxx:DisplayMode>\n </gpxx:WaypointExtension>\n"))
There's a yes/no box below - yes seems to mean "try again" and no means "don't". After clicking "no" you do get a "view data" option showing the osmchange xml but that's probably not a lot of use for newbies.
To see the problem try this:
http://www.openstreetmap.org/edit?editor=potlatch2&gpx=1056198
Zoom in and convert the orange dot north of the road to a node and try and save it.
In this case the extra-long value is created by a Garmin GPS. There are other long value trac bugs related to merged Tiger data (3846 open and 3587 closed) but this is a different aspect of the problem.
Edits can be lost due to this problem if you've done a lot of edits prior to a save and don't know where the offending waypoint that's causing the problem actually is.
Among the possible solutions are:
Filter "extensions" from the list of tags moved from the waypoint to the node (Potlatch 1 does this) - that would solve the issue I'm seeing with Garmin data but wouldn't affect the problem if someone found another way to cause it.
Position the user in the editor to the first offending item and allow them to edit it manually (harder, and might be time consuming if lots of items have the problem).
The text was updated successfully, but these errors were encountered: