Jump to content

Added a new entry


Lat34North

Recommended Posts

I am trying to add a NEW entry for the "American Civil War Monuments and Memorials" category that is located on the Chickamauga Battlefield. There are many enterers in the category near this marker, but this is a new one that has not been previously waymarked. I submitted this monument and got the screen listing other monuments close to this one as expected. I cheeked, and this is a NEW one, but when I select "save anyway", I get the following error message.

 

You have previously created a waymark that exactly matches the one you are trying to create right now. You need to differentiate it somehow by adding more information, like a unique coordinate for example.

 

New monument is: Benjamin H. Helm Memorial Shell Monument

Coordinates: N 34° 56.019 W 085° 15.168

 

Closest monuments showing in the messages are:

Wright’s Brigade Plaque - Chickamauga National Battlefield

Scogin’s Georgia Battery Plaque - Chickamauga National Battlefield

Calvert’s Arkansas Battery Plaque - Chickamauga National Battlefield

Croxton's Brigade Plaque - Chickamauga National Battlefield

Link to comment

I've had that happen when the site hiccupped when I did a save or submit, and it actually did save it, and then tried to re-save or submit it. (Perhaps a double click or something?) Check your unfinished waymarks before doing anything to it. You may already have it there in your unfinished.

 

Listen to Mountainwoods. This has happened to us and it is always the result of the hiccup he mentions.

Link to comment

It was not in my list of unfinished, first thing I checked. I was able to submit it today (1/17/2017). Was rather frustrating since each time, I had to redo everything. All is right with the world, or at lest the Waymarking portion, now. Thanks for the feedback. Oh, I did change the coordinates slightly, made the N 34° 56.0185 W 085° 15.1685. Of course, this got rounded off to what I had originally.

 

Byron

Link to comment

Glad to hear you got it working.

 

When the waymark is approved, would you please include a link to it here? I'd like to check something out. I noticed that you are using 4 digits after the decimal point which, I think, sometimes causes a problem when attempting to view the waymark. At least, I know of two other waymarks that always give errors when attempting to view them (you have to "trick" Waymarking by attempting to do an edit suggestion on them just to bring them up!), and in both cases they have 4 digits after the decimal point instead of three. Thanks.

Link to comment

Sure, I normally only do 3 digits (see original post). I just did 4 in a effect to work around the ordinal problem. When I input my latest, the 4th digit was truncated. It is still pending, but it is at

 

N 34° 56.019 W 085° 15.168

 

http://www.Waymarking.com/waymarks/WMTX4X_Benjamin_H_Helm_Memorial_Shell_Monument_Chickamauga_National_Military_Park

Edited by Lat34North
Link to comment

Glad to hear you got it working.

 

When the waymark is approved, would you please include a link to it here? I'd like to check something out. I noticed that you are using 4 digits after the decimal point which, I think, sometimes causes a problem when attempting to view the waymark. At least, I know of two other waymarks that always give errors when attempting to view them (you have to "trick" Waymarking by attempting to do an edit suggestion on them just to bring them up!), and in both cases they have 4 digits after the decimal point instead of three. Thanks.

 

This is interesting. Are you saying that FOUR is the magic number, or is it anything over three? Also, are you actually able to see the four digits on the waymark's page? I never have seen that!!!

 

I used to truncate to 3 but decided a few months ago not to bother (greater precision, right?) and had no idea this might cause problems. Mine now are submitted with a random number of digits, whatever comes off the GPS. Most end up between three and six in length after the decimal. It seems to me that the site will accept seven.

 

This is a few years ago, but I seem to remember that the reason I began truncating to three digits was because of having random weirdness associated with longer strings.

 

Darn, now you've got me wondering if Waymarking uses more than the three digits (when they exist) internally or if all calculations are done to three digit precision. Truth be told, though, it matters naught!

Link to comment

I'm just guessing -- trying to look for commonality. It looks like the 4 digits isn't the problem, since the new (pending) waymark looks good, and has automagically been rounded to 3 digits.

 

It's just that the only 2 examples I've bumped into over the years are ones that, when you can get to them, they have 4 digits after the decimal point. But by the looks of it, that is just coincidence.

 

One of the waymarks is in the town near me named Exeter, and it is the Exeter Warning Siren. If you can get the waymark in a search results (I used nearby waymarks on a different Exeter waymark), then you can click on the little Log It! icon in the upper right corner of the listing in the search results. But you can never get into the waymark page itself.

 

Anyway, 4 digits isn't it. There's something else that causes some waymarks to be messed up.

Link to comment

Interesting bug, WM2X8Q and WM2X8P (nearby in time and space) are fine but not WM2X8N.

 

According to the edit page of WM2X8N, the co-ordinates are as follows.

N 36° 40.38 W 93° 56.742

 

I suppose I could just start the edit process and the bug might disappear but then the mystery would remain a mystery.

Edited by elyob
Link to comment

Interesting bug, WM2X8Q and WM2X8P (nearby in time and space) are fine but not WM2X8N.

 

According to the edit page of WM2X8N, the co-ordinates are as follows.

N 36° 40.38 W 93° 56.742

 

I suppose I could just start the edit process and the bug might disappear but then the mystery would remain a mystery.

 

I think the problem with that one, whatever it is, is terminal I edited it, changed the 93 to 093, then changed the 40.38 to 40.381. Neither had any effect. I edited in the long description. Nothing. I did notice that the system always adds a "2" to the end of "40.381", giving it 4 digits of precision. I even extended both long and lat to 6 digits. It always comes back the same, with the same error.

Link to comment

Interesting bug, WM2X8Q and WM2X8P (nearby in time and space) are fine but not WM2X8N.

 

According to the edit page of WM2X8N, the co-ordinates are as follows.

N 36° 40.38 W 93° 56.742

 

I suppose I could just start the edit process and the bug might disappear but then the mystery would remain a mystery.

 

I think the problem with that one, whatever it is, is terminal I edited it, changed the 93 to 093, then changed the 40.38 to 40.381. Neither had any effect. I edited in the long description. Nothing. I did notice that the system always adds a "2" to the end of "40.381", giving it 4 digits of precision. I even extended both long and lat to 6 digits. It always comes back the same, with the same error.

I've had to change coordinates on a waymark before (both saved and fully submitted) and it often throws in a random fourth digit. The way to circumvent that is to put in a deliberate fourth digit of zero. So instead of changing 40.38 to 40.381 you need to change it to 40.3810. Mathematically they are the same, of course; but character-string-wise, they are not.

 

I believe the random 4th digit is a common programming issue. The developer is using something like strncpy or memcpy in C/C++, or some equivalent in Java, but they forget that those do not automatically put an end-of-string NUL byte into the destination buffer. So whatever happens to be there in memory from earlier actions ends up attached to the end of the string. The developer should have either used memset (C/C++) or equivalent in Java before using strncpy or memcpy (to set the entire destination buffer to NUL bytes), or they should have made sure that the byte after the copied bytes is deliberately set to '\0' (NUL), or they should have simply used strcpy instead, depending on how the data is stored.

 

Fortunately, now that I'm retired, I don't usually have to diddle with such bugs. Though I do still do some programming on my own interpretive language that is similar to, but much more powerful than awk or its enhancements (nawk, gawk, and so on).

Edited by MountainWoods
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...