Jump to content

Emojis, GPS receivers, and GPX files


Dr.MORO

Recommended Posts

Hi all,

 

Quick question: Does your handheld GPS device (excluding smartphones) properly show Emoji characters on-screen?

 

Why ask?

Well, my trusty Garmin Oregon 450 does NOT show Emojis contained within the Geocaching GPX files, and Garmin confirms "The device does not support the use of emoji characters." when asked.

 

Are Emojis playing nice with your GPSr, and GPX files?

Or, is it an issue to be solved somehow (New GPX scheme? New GPSr?), being in a Geocaching era of Emojis and smartphones?

 

Which handheld GPS device do you use for Geocaching, and does it show Emojis properly on-screen?

 

Looks for some answers...

Link to comment

Are we talking about ascii emojis being presented as little pictures, or are we talking about special characters in general and just worrying specifically about those from emoji character sets? If it's the latter, I have this problem more often with characters from other languages than I do with emojis.

Link to comment

I load caches to my Garmin 62 via GSAK.  Sometimes, special characters foul up the entire waypoint load.  In GSAK the special characters show up as question marks.  When I see these, I put the cache on my ignore list so it doesn't mess up loading the caches I want to find.

 

So, while the hider might think that emoji's make their page look fun or pretty, they're unintentionally screening out potential finders of their cache.  At least this one.

  • Upvote 1
  • Love 1
Link to comment
16 minutes ago, arisoft said:

The problem, as far as I know, is that some devices may crash or function erroneously when there is unsupported UTF-codes (emojis) in the GPX file. If programmed correctly, the device should skip unsupported codes and nothing special happens.

It sounds more like the OP is only worried about displaying them. Surely modern Garmin devices don't crash, do they?

 

If the problem is crashes, then the question should clearly be expressed as a problem with UTF codes, not with the somewhat trivial subset of emojis. Emojis are just people playing around, so someone making decisions might consider them unimportant, but an unsupported UTF code could be a reasonable and predictable attempt of COs to use their native languages. But, of course, I agree all devices should handle that kind of stuff gracefully.

Link to comment
5 minutes ago, Mineral2 said:

But it's the emoticons that trigger emojis to display as such, as long as the code detects and converts them.

 

You are referring to smileys inserted between brackets when you post new log entries. They are just ASCII characters. Emojis are totally different thing. See the link from my post.

Link to comment

Hi all, and thanks for all the input so far.

 

My initial question is about GPSr and Emojis, but I know this all goes even further into a rabbit hole of UTF-codes and Unicode versions, as well as other languages.

On a side note, I have already proven that a simple Emoji character input into Google Earth Pro Mac desktop app, will corrupt the myplace.kml file as posted on Google forum.

Google forum "Warning! Emojis corrupt my places KML file in desktop Google Earth Pro?"

 

To me, many things related to GPX files, Google Earth Kml files, and GPSr, including Geocaching, has NOT caught up with the newer character codings which is seemingly changing even faster with newer Emojis and such being added every year or so.

Perhaps, the GPX file schema 1.1 is becoming outdated, and is incompatible with the Emojis characters from the start?

 

In any case, I have received another reply from Garmin to my questions:

Q: Is there any Garmin handheld GPS device sold today that is compatible, and displays Emoji characters properly on-screen? If so, please specify the model.

A: There are none that are available at this time.

 

Q: If not, then is there any future plans at Garmin to have these Garmin handheld GPS devices become compatible with Emoji characters?

A: As for any known plans I have not heard anything about the emojis. I would recommend to follow the link below to our idea page and submit this as the more people request certain things the higher the chance of getting these type features added.

 https://www.garmin.com/en-US/forms/ideas/

 

I am wondering what GCHQ is thinking about the Emoji issue in GPX files as Geocache names and in the logs.

Not worried?

Or, planning for a change?

 

The rabbit hole continues...

Link to comment
1 hour ago, Dr.MORO said:

Perhaps, the GPX file schema 1.1 is becoming outdated, and is incompatible with the Emojis characters from the start?

 

A GPX file dowloaded from geocaching.com starts with this statement

<?xml version="1.0" encoding="utf-8"?>

 

This means that the file is using UTF-8 which contains the emoji block. My own device is using a pocket query GPX file for all solved mystery caches and it displays emojis correctly for them. There is no problem with the schema or file.

  • Upvote 2
Link to comment
2 hours ago, arisoft said:

 

A GPX file dowloaded from geocaching.com starts with this statement


<?xml version="1.0" encoding="utf-8"?>

 

This means that the file is using UTF-8 which contains the emoji block. My own device is using a pocket query GPX file for all solved mystery caches and it displays emojis correctly for them. There is no problem with the schema or file.

 Which GPS device do you use?

Link to comment
3 hours ago, arisoft said:

 

It is a mobile phone but the source is a GPX file downloaded from a pocket query. 

 

Mobile phones are NOT in question here, hence my initial question says 'excluding smartphones'.

The smartphone OS and it's app can handle the Emoji characters.

 

I am asking about handheld GPS receivers here, the ones for outdoors hiking and such like from Garmin, etc.

Edited by Dr.MORO
Link to comment

As far as I know none of my GPS receivers will display an emoji but I'm not concerned. As The Leprechauns pointed out above, GSAK displays these as question marks and I filter, delete, and ignore all caches with question marks before they go on a GPSr. If this thread is about changing the GPX schema or GPS firmware to allow viewing an emoji on a GPSr I vote NO, why spent time and resources reinventing the wheel in order to see something cute that has nothing to do with navigating to a cache? 

  • Upvote 1
Link to comment
3 hours ago, 31BMSG said:

As far as I know none of my GPS receivers will display an emoji but I'm not concerned. As The Leprechauns pointed out above, GSAK displays these as question marks and I filter, delete, and ignore all caches with question marks before they go on a GPSr. If this thread is about changing the GPX schema or GPS firmware to allow viewing an emoji on a GPSr I vote NO, why spent time and resources reinventing the wheel in order to see something cute that has nothing to do with navigating to a cache? 

Unless something very odd is going on that I don't understand, the GPX schema already allows UTF-8 encoded emojis. The only question is whether any GPSr manufacturer feels a need to display them. If any GPSr crashes when encountering a UTF-8 character it doesn't understand, that's a bug that should be fixed.

  • Upvote 1
Link to comment
5 hours ago, Dr.MORO said:

 

Mobile phones are NOT in question here, hence my initial question says 'excluding smartphones'.

The smartphone OS and it's app can handle the Emoji characters.

 

I am asking about handheld GPS receivers here, the ones for outdoors hiking and such like from Garmin, etc.

 

Do not move the goal. I answered to your wrong assumption:

 

21 hours ago, Dr.MORO said:

Perhaps, the GPX file schema 1.1 is becoming outdated, and is incompatible with the Emojis characters from the start?

 

The file is ok because it works with smartphones correctly. Your device is not compatible with the file.

Edited by arisoft
Link to comment
7 minutes ago, dprovan said:

Unless something very odd is going on that I don't understand, the GPX schema already allows UTF-8 encoded emojis. The only question is whether any GPSr manufacturer feels a need to display them. If any GPSr crashes when encountering a UTF-8 character it doesn't understand, that's a bug that should be fixed.

I was just adding my 2 cents to the question arisoft just answered above, for my uses I see no reason to change anything.

  • Upvote 1
Link to comment
1 hour ago, 31BMSG said:

I was just adding my 2 cents to the question arisoft just answered above, for my uses I see no reason to change anything.

I do consider it important to think many times before changing something many people have to adapt to, like the GPX file schema, so I was just acknowledging your concern on that score while saying I don't think this problem is in that class. In particular, we don't have to worry about Groundspeak resources being spent on this 'cuz it seems to be in the hands of the GPSr manufacturers.

 

There's also a chance that the problem is trivial, like just providing the emoji character set to an existing infrastructure in the GPSr that handles foreign languages, so I kinda want GPSr people to think about it instead of thinking it's "obviously" such a big problem, they should ignore it.

Link to comment

There are a lot of related terms being used interchangeably in this thread that are different at an engineering level.

Emoticons are different than Emoji. They both display (typ. human) expression ina way that allows expression of the art ("house" or "smiling girl").


BBCODE is the thing that leaks from the forums into some cache page descriptions that transforms square brace stuff into icons or text markup. 


A BBCODE symbol or an Emoji may result in single character or glyph resulting not  typically easy to create  from a key on a keyboard.


GPX (any version) allows encoding any Unicode character, which may or may not be Emoji. It can also signal things like for bolding text until which, if missing, may cancel at the end of thie next work ,paragraph, sentence, block, or the end of the world. BBCode is very poorly specified and remains largely the bulletin boards of the 90s.
It's very rare that any handheld GPS (indeed, much of anything) will render everything that may be represented in Unicode. Another bazinga! is unicode (buried in UTF-8 thta's like " RLO (U+202E RIGHT TO LEFT OVERRIDE" which changes layout from right to left, which is a buzzkill for our languages but needed  for others.

 
Any creator of GPX can create something that can cause indigestion for some reader. For example, you could have a single field in GPX that's a terabyte long (assuming it's properly encoded) and that's going to trigger bad behaviour in _something_.  Coming down from the silly cases, Garmin's GPX reader is pretty well known to crash on invalid GPX and some valid GPX. It gets better on some devices in some versions, but it seems like there's always *something* that'll crash them. It could ignore bad things or issue an error or do lots of other things, but crashes are just how they do it. If you pound them with a specific GPX file, long enough, they may fix it.


Validating GPX is easy, and is encouraged by the GPX Developers. It's an easy way to draw a line in the sand on whether a GPX file  is correct. Now "correct"  and "works like you want" may be fine lines - for example, the GPX spec doesn''t stop you from putting <html><script>alert();</script><html> inside a name and that may render OK in some places with enough resources to embed an  HTML/CSS renderer and a Javascript engine (cache pages rendered to a web browser allow a very tiny subset of HTML. Earth allows it in certain contexts like inside a balloon, but not inside a name) but they're just not going to display well on a device with constrained resources. Certain Garmins, for example, crash if they see lower case letters or spaces (honest!) so readers of GPX that have to send to such stupid devices have to try to do something to make it more palatable to the device.
 

This is why GPSBabel (and thus both GSAK and Google Earth) crawls through broken glass to ensure that the amazing, rich GPX makes it to the Garmins (and hundreds of other GPS receivers) by trying to keep the character of the name, but it's admittedly very American English oriented. If you have  caches named "P and Grab 2" and "P and Grab 21" and it's going to a yellow etrex (Upper case, no spaces, asdii, no conflicting names" we'll compress frirst "PANDGRAB2" and  "PANDGRAB21" but the numbers are outside the length. We'll then start shoving the number back and the end, treating the number as more unique than the prose. P&GRAB2 and P&GRA21". Then another pass is made to dee if ampersand is actually allowed. That  mapping of knowing the limits of the devices and trying to take the thorns off the data as it goes through the device is difficult.

Figuring out what is actually allowed where and when can be a crazy project of its own. (I'm about 19 years into that. )
"

When chasing  this class of bugs, context matters a lot, so be careful to not oversimplify your test case. It's also why arguing about a single line of XML in a forum is a trap. Those "is_xhtml" fields in Groundspeask;s XSD, for example, change a lot of the rules.
 

Editorial: The useful set of Unicode for cache pages is much more stable than the set of Emoji. The latin-based languages other than English, for example, are quite fond of diacriticals. There are humans (that are geocachers) that cannot represent their own given names with strict ASCII so Unicode is the standard way to represent the o with aorn umlaut as number X and we (the computer industry) all pretty much agreed in the early 90's that Unicode would be the way we encoded such things. Accent graves, even country flags all seemed pretty reasonable. A smiling face? OK, we don't know what it'll look like but that seemed reasonable. A brown smiling face? OK. A Brown smiling female face? OK. Keep on this path until you have about a dozen modifiers for faces and you end up with an explosion in this space. The 2,789 emojii in Unicode v11 (many new, and there were many more not accepted) are simply not going to make it to your 13 year old Nuvi  350. It would be entirely possible (easy, and responsible) to read them and toss them or replace them with the next level down if in face code block or something. As an engineer, "ignore the problem and let it crash?  violates my interpretation of Postel's Law and as a former OS guy, "crashing the entire device" should be best reserved for cases like the device being physically ablaze...and have a rollover process to a machine in the other building to handle that...But recognizing that P&G should be represented  and read as P&and;G grab in most context and to come out of the SAX/DOM parser in three tokens, "P", either :"and" or "and;" depending on wheither the lexer or the scanner is first, followed by a token of "g" - and it all depends on the surrounding context - a <blockquote" or an embedded <html>can all change how those three characters actually get stored and sent and everyone involved declaring the right things are done at the right time because if you do it but thosee notifications don't stay in sync, hilarity ensues. Not everyone decided to have the artwork for "dark female zombie running" included into the standard. At some point, the creator is asking an artist to create a representation of their creation for each of the devices that cares, all so they can be rendered interchangeably iwth a few (fiv5 or six) bytes. At some point,a lot of this should  get compressed down to a JPG or GIF or whatever and served by the network for somebody to the world, like a real picture.


I helped create several of the things being discussed in this thread. It's late as I write this, but if anyone really wants to argue specifics about angle brackets, I'm probably  as qualified as it gets.

I think the overall TL;DR of "if you put real unicode into a cache page description, such as the language used in the country  in or near wher the cache is located, with proper handling in the apps and the hardwarre, you'll probably be fine. If last week's Emoticon (they tend to move fast) it may work on some devices and not on otherrs. If you need to see if a GPX file is valid, the process is at https://www.topografix.com/gpx_validation.asp it needs minor mechanical tweets for geocacching's extensions) but you can then at least put "blame" on reader vs. writer. It is my religion, for example, that any GPX that validates shall never crash code of mine (That's not a dare to find such a case; it's a sign that if you find one, I'll probably fix it, even if "fix" it means "don't crash".)

The GPS Schema  is fine. I've not analyzed the Groundspaek one. Based on what your'e describing as your motivation, I'd reduce that to the simplest possible case to on the SD card and then send Garmin that SD card and a GXP and ask them weekly what the status of the fix that makes that unit CRASH when reading the file.  Convinced them that this same gps is being used for navigation and crashes are bad for navigating  and maybe you can get it escalated from "game play disrupted" to "potential vehicle crash from distracted driver" 

It's complicated.

  • Upvote 2
  • Helpful 3
Link to comment

I wonder if there are caches out there that require emoji or emoticons be displayed to solve a puzzle of some sort. I have not seen any, but they almost certainly do exist. Probably created purely with a mobile phone in hand, which means traditional cachers that use dedicated GPSr devices may not have the right equipment to solve them. So what. There are plenty of caches that require some additional equipment beyond a smartphone or GPSr to complete. 

 

I am not interested in requesting Garmin (or any other dedicated GPSr developer that may still exist) take resources away from current development to try and make my GPSr act more like a smartphone. Everyone wants a single 'do-it-all' device, but dedicated devices will always outperform them when used for their intended purpose. I like my dedicated GPSr because they are not smartphones. If I wanted to use a smartphone that can display emoji or emoticon symbols, I would. And I would encourage others to do the same if that is a necessity for them.

Edited by Atlas Cached
Link to comment
3 hours ago, Atlas Cached said:

If I wanted to use a smartphone that can display emoji or emoticon symbols, I would. And I would encourage others to do the same if that is a necessity for them.

 

Sounds dismissive when you put it that way.

 

I don't care as long as the "boundary" of the bug is the emoji itself, ie, that one character just doesn't display correctly.  (The Garmin reps on the phone would probably roll their eyes if they thought it was as simple as this.)

 

If it becomes, in effect, a small explosion that causes the entire listing, or database, or hardware unit to fail, that's a serious problem.   Every so often there's a thread here, someone can't go out caching because a single goofy cache listing borked their GPX.

 

This is one reason I love caching with a phone.  Bugs are fixed all the time, without fuss.

Link to comment
16 minutes ago, arisoft said:

 

Is it a multi-cache if you can do it with a GPSr only. ?

Not necessarily. There are puzzles where you only have to read the description to get clues, or make calculations, and you can do that on a GPSr, though it is still easier to read long descriptions on the website. But there are some that REQUIRE the use of a browser to view source or download an image, etc. Puzzles using emojis would therefore require the use of a browser or app to solve, so do not really introduce a unique problem to the game.

Link to comment

...and nobody has yet brought up that emoji and/or emoticons are not always displayed the same way across platforms?

 

Same code can have a totally different image displayed on two different devices.

 

So, if this function were added to a GPSr, how do you determine which version of each emoji or emoticon should be displayed on the device?

  • Upvote 1
Link to comment
17 minutes ago, Atlas Cached said:

...and nobody has yet brought up that emoji and/or emoticons are not always displayed the same way across platforms?

 

Same code can have a totally different image displayed on two different devices.

 

So, if this function were added to a GPSr, how do you determine which version of each emoji or emoticon should be displayed on the device?

Well, yes, but wouldn't anything be better than nothing? I'm not a fan of emojis, so I don't care whether a GPSr developer feels like adding support for them, but I wouldn't discourage them just because there's a chance their smiley looks different than the smiley on my computer. Having something I might be able to recognize seems better to me than having a white box that's sure not to give me any information. (And that's assuming a white box. Sometimes the developer "doesn't support" funny characters by just throwing them out, leaving no evidence they were even there.)

Link to comment
17 minutes ago, dprovan said:

Having something I might be able to recognize seems better to me than having a white box that's sure not to give me any information.

 

My Firefox browser displays the hex code of the unknown emoji. I can easily check the correct interpretation from the codebook. Any device could display the unknow symbol by using the code of the symbol.

Link to comment
13 hours ago, Atlas Cached said:

...and nobody has yet brought up that emoji and/or emoticons are not always displayed the same way across platforms?


I intended to, but there's only so much I could do on a phone from bed. :-) <- Emoticon. [:-)] <- bbcode ?<- Emoji

This is already a tangible problem with existing devices. Each group has teams of artists that decide an overall look to the set (and to handle the approximate 60 added each year). As one example that I know pretty well, my employer tried to abstract that whole human face thing away and use "gumdrops" that kept the spirit of "face, smiling". Some people loved them, some didn't. https://emojipedia.org/google/android-7.0/ vs https://www.wired.com/story/google-emoji-redesign/

You can see samples of representative artwork many places, but just sampling:
https://www.unicode.org/emoji/charts/emoji-released.html Now if you're looking at Expedia inside Facebook on a Samsung device with a Google OS or browser, which one do you get? Darned if I know. It may even be different on the same device if you're using Samsung's browser instead of Google's own and even though the Samsung OS is derived from Google's. If you typed a note on your Samsung that relied on one that they removed or changed in a recent OTA update, what happens to your document? Hint, "There's just no guarantee it will display as intended on a recipient phone."  Firefox's handling of dumping hex or leaving blanks or "funny characters" are all just as valid, though questionably usable. (In the developer's console where you can zoom on them, those numbers actually are readable...) Unicode is just now working with diversity (2.6) and how to handle groups of differing ethnics and races in groups. I don't envy ther work very much these days.

One point of Emoji over just shipping pixel-precise data objects with a picture is exactly to allow such artistic creativity and visual diversity. If your cache page relies on the presence of dimples in your winking face, something has gone very, very wrong.

GPS icon sets have always been messy to convert.  GPSBabel tries to get Magellan's "Home" to Garmin's "House" and "cross, red" to "emergency services" (I'm pulling loose examples from memory...) but even within Garmin's own product lines this has historically been messy. Garmin devices don't tell the computer what they do support and Garmin has at least two numbering systems they use for each Garmin icon as you can see in our code.  (The Quest and Rhino, of all forgotten devices, went totally nuts with emoji-like icons, none of which are related to Unicode names, of course.) GPSBabel even crawls through glass to try to get Delorme AN1 icons and a bunch of others and I've not seen any portable device try to tackle emoji - they're only now really starting to get Unicode right and still tripping over UTF-8 vs. UCS-2 with a few vendors still throwing DOS code pages into the mix.  (Loggers tend to really like UCS-2 for ASCII for some weird reason. Most odd numbered bytes are totally wasted...)



If if becomes a problem to geocaching.com, it's easy to imagine them simply filtering out the Unicode blocks for ED-20 -- ED-26 from cache pages, user names, and such. That's arguably the "no fun" approach, but it would allow them to focus on the real problems surrounding l10n and i18n issues. I'd certainly do the same for GPSBabel. Unless a customer came to me very badly (with an open checkbook) to address problems in this space, it's just not at the top of my list.

Hopefully, by this point in the conversation, we're approaching an end as we we've educated at least a few people that arbitrary emoji are a crazy hard - and still growing - problem for devices and environments with constrained resources. Anything that *has* to be interpreted (or even presented!) unambiguously by a reader should not rely on emoji.  We've explained while there is some industry uplift that trying to support emoji generally also improves internationalization, you're simply not going to see a lot of manufacturers getting excited about letting anyone name a waypoint an emoji and deal with the issues of screen resolution to support "six mixed gender people holding hands" and dealing with issues like how to present that in the sort order of the screen, how you enter such a character with a click stick, and so on. GPX (via XML) allows you to represent such things, but my forecast is that you won't see it in outdoor-grade (or even PND) GPSes like we tend to deal with in this forum.  The more traditional operating systems dealing with mass market and that can rely on higher res screens and a more diverse user base are more likely to track developments here just from market pressure and because those devices are much more capable.  The GPX group is a much smaller group that considers it largely a Unicode issue but we'll need to know what kind of devices woud be ready. I can't imagine that Garmin II is going to be bitten by a radioactive spider and get Unicode supwerpower support.


OP, Do you consider this question sufficiently answered now?

  • Upvote 2
  • Helpful 3
Link to comment
23 hours ago, arisoft said:

My Firefox browser displays the hex code of the unknown emoji. I can easily check the correct interpretation from the codebook. Any device could display the unknow symbol by using the code of the symbol.

Admittedly, a number is a little better that nothing, but I'd still rather have a smiley face and the only issue is whether it's smiling or grinning. A number's going to do me zero good out in the field. In GPSrs, I'd normally expect a vacuous character rather than a number since it's more likely to maintain the formatting even though personally I'd normally like the number. But, then, I always was amused when my old PN-40 would show HTML code (including comments) because it didn't know what else to do with it.

Link to comment
On 12/31/2018 at 3:41 AM, robertlipe said:

OP, Do you consider this question sufficiently answered now?

 

Thank you so so much, robertlipe, the Chief Babel-Head, for both of your super-detailed yet understandable explanation from the possibly most appropriate person to answer. Truly appreciated! (insert two continuous thumb-up Emoji here, with wink emoticon)

 

And do I consider this question sufficiently answered now?

Q: Does your handheld GPS device (excluding smartphones) properly show Emoji characters on-screen?

Hmmm, good point. Probably yes.

I totally understand that present handheld GPS receivers will never be able to properly display all Unicode (including Emoji) characters as how they are meant to be, no matter if within GPX file or else.

Thanks for that.

 

Then, the next question in my head:

"Is it an issue to be solved somehow (New GPX scheme? New GPSr?), being in a Geocaching era of Emojis and smartphones?"

To be a bit more specific, would there ever be in the near future, a GPS device that is as accurate and as quick as the present outdoors hiking handheld GPS receivers like a Garmin Oregon, while also being able to display all the latest character sets & languages on-screen like our present smartphones and it's OS? Best of both, in one?

I would love to have such GPS device, and wondering why there isn't any available.

I do understand there could be many issues to overcome to make this happen: Smartphone OS onto GPS handheld? Or, transform smartphone into a better GPS receiver?

 

Sorry, but answer to one question just leads to more questions... a mad scientist's norm (Tonge-sticking winking Emoji here)

Emoji characters are here to stay, and something has to change for the better future. Ignoring the issue leads to no future.

For now, parsing and filtering out the unsupported Unicode (Emoji included) characters from my GPX files before loading into my Garmin Oregon, will be my stopgap drill.

 

The rabbit hole still continues...

 

Happy New Year 2019!

Link to comment
59 minutes ago, Dr.MORO said:

"Is it an issue to be solved somehow (New GPX scheme? New GPSr?), being in a Geocaching era of Emojis and smartphones?"

 

You can solve the issue by purchasing a device which supports emoji characters. Just keep asking from manufacturers. At some day you may find a compatible device and you can report you success to this thread.

Link to comment
41 minutes ago, arisoft said:

 

You can solve the issue by purchasing a device which supports emoji characters. Just keep asking from manufacturers. At some day you may find a compatible device and you can report you success to this thread.

 

Thanks for your reply, arisoft.

At present, unfortunately the answer is, there is no known commercial handheld hiking GPS receiver (NOT including smartphones, as I have said repeatedly) sold that properly displays latest full Unicode character set, yet. So, the issue unfortunately cannot be solved fully, at this moment. And yes, work arounds can be applied.

Hope is there to someday have this fully resolved, although only if we continue asking for it.

One day, hopefully soon.

Link to comment
2 hours ago, Dr.MORO said:

 

To be a bit more specific, would there ever be in the near future, a GPS device that is as accurate and as quick as the present outdoors hiking handheld GPS receivers like a Garmin Oregon, while also being able to display all the latest character sets & languages on-screen like our present smartphones and it's OS? Best of both, in one?

I would love to have such GPS device, and wondering why there isn't any available.

 

The rabbit hole still continues...

 

Happy New Year 2019!

 

Such a device (meeting your above quoted requirements) does exist.

 

:mellow::huh::o:lol::D

 

 

Link to comment
5 minutes ago, Atlas Cached said:

 

Such a device (meeting your above quoted requirements) does exist.

 

:mellow::huh::o:lol::D

 

 

 

Thanks, Atlas Cached!!!

Oh, how did I miss this Garmin Monterra®???!!!

Hmmm, $649.99 USD...

https://buy.garmin.com/en-US/US/p/113522

As for function, not bad at all. (one thumb up Emoji)

Has anyone actually tested and can confirm all latest Emojis and Unicode character set (even right-to-left languages) are displayed properly? Or at least for Geocache names and logs containing Emoji characters? The Garmin customer support never mentioned the Garmin Monterra model being compatible with Emojis, and just said none from Garmin are Emoji-compatible at present. Weird. Will ask them about the Garmin Monterra model and Emoji again.

 

Also, any competitors from other GPS device manufactures?

Link to comment
4 minutes ago, Dr.MORO said:

 

Has anyone actually tested and can confirm all latest Emojis and Unicode character set (even right-to-left languages) are displayed properly? Or at least for Geocache names and logs containing Emoji characters? The Garmin customer support never mentioned the Garmin Monterra model being compatible with Emojis, and just said none from Garmin are Emoji-compatible at present. Weird. Will ask them about the Garmin Monterra model and Emoji again.

 

 

Not likely, as the device is no longer supported by Garmin, and will only have support for apps ect. that run on it's now old and tired Android OS. It still work just as well as it ever did, but newer apps in the play store are not usually compatible with older OS versions, so YMMV.

 

Link to comment
1 minute ago, Atlas Cached said:

 

Not likely, as the device is no longer supported by Garmin, and will only have support for apps ect. that run on it's now old and tired Android OS. It still work just as well as it ever did, but newer apps in the play store are not usually compatible with older OS versions, so YMMV.

 

 

No wonder...

Thanks.

 

So, maybe not solved yet again?

Link to comment

Okay, arisoft, maybe using smartphones with add-on GPS receivers may be the future and the solution to the Emoji issue after all.

 

A quick web search shows several bluetooth-connected GPS receivers for smart devices (smartphone & tablets), and maybe there are more on the market.

  • Bad Elf GPSr
  • Garmin GLO 2 GPSr
  • Dual Electronics GPSr

 

Unfortunately, this does not solve the Emoji issue for those using Emoji-incompatible devices at all.

Smart device users just benefit from the latest technology.

Link to comment
3 hours ago, Dr.MORO said:

Emoji characters are here to stay, and something has to change for the better future. Ignoring the issue leads to no future.

Emoji characters might be as impossible to eradicate as vacuous uses of "like" in the middle of a sentence, but they are similarly pointless, which is why no one's, like, lost any sleep over supporting them in GPSrs. ☺️

  • Funny 1
Link to comment
3 hours ago, dprovan said:

Emoji characters might be as impossible to eradicate as vacuous uses of "like" in the middle of a sentence, but they are similarly pointless, which is why no one's, like, lost any sleep over supporting them in GPSrs. ☺️

:D

For us, it's the use of "I mean" at the beginning of a conversation.  It's not that they're correcting something said earlier...  :)

Link to comment
10 hours ago, Dr.MORO said:

Has anyone actually tested and can confirm all latest Emojis and Unicode character set

 

I am sure it can display emoji charactes correcly. But the device can not download data from Groundspeak because of outdated OS version.

Edited by arisoft
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...