Extra_POI_Editor - A tool to View/Edit/Convert POI/TourGuides (Part 2)

 

This thread is a continuation of the original thread here: http://www.poi-factory.com/node/21156

What is Extra_POI_Editor?

It does too many things for me to explain in a short post, so let's say it will allow you to view, edit and convert any GPX/CSV/OV2/JPG/KML/MGLN POI file to GPX/CSV/OV2/KML. Yes! Geocoded JPG can be imported too!

* There are preview windows specially designed to simulate a 4.3" widescreen GPS like a nuvi 760, but the program will work for other GPS; the display in the program will not match exactly the non-widescreen GPS.

* The tool will allow you to see the POIs on a map. You can drag also the marker on the map and update the new coordinate. This is very cool to fine tune the POI location.

* You can also preview linked images and sound files used in TourGuides.

* EPE can do batch geocoding and reverse geocoding. It has special filters to extract State, Postcode, Phone and more. You can create custom column formats for your CSV files input and output, ...

* You can open POI Loader, MapSource or GoogleEarth directly from EPE to see all POIs on the map.

This is it for now. It does more than that and will probably do more later. Please post your comments and suggestions here.

Turbo.

The EPE page and download links are here:

http://turboccc.wikispaces.com/Extra_POI_Editor

As usual, if you find something missing just post your requests. I will see what I can do.

1 2 3
5 6 7 8 ... 13
<<Page 4>>

EPE v4.84 is posted

Hi,

I just poasted EPE v4.84. Many fixes. I strongly recommend to update to this version. The link in post #1 is still valid to get the latest version.

Turbo

.

Thanks, bud! Awesome as always...

--
nüvi 3790T | Those who make peaceful revolution impossible, will make violent revolution inevitable ~ JFK

Thanks Turbo. Truly thankful

Thanks Turbo. Truly thankful for your hard work on this program.

--
All the worlds indeed a stage and we are merely players. Rush

THANK YOU

Thank you for all the hard work you do with EPE.

--
Nuvi 660 owner.

Link

turboccc wrote:

The link in post #1 is still valid to get the latest version.

For those that don't have it, it's: http://turboccc.wikispaces.com/Extra_POI_Editor#toc5

--
nüvi 3790T | Those who make peaceful revolution impossible, will make violent revolution inevitable ~ JFK

did this comment get lost?

KenBushaw wrote:

I just created some new files and converted a LOT of files from csv to gpx using EPE 4.83. I notice in preferences, the line break pick lists are set to LF but when I hex edit the gpx files, I see CRLF's.
When do the settings apply?
Or is there a bug?

Thanks,
Ken

I haven't heard anything so am wondering if this question got overlooked.

Also, I am wondering why the default line break setting is LF instead of CRLF.
May be a good reason so I would like to know.

Thanks,
Ken

--
Ken

Enhancement Request

Turbo,

Would it be possible for EFE to fill in some of the Contact Info fields on the POI Edit window based on the Lat/Lon?

Currently, when a POI is created from a photo the cooridates are written into the Post Code field. I think that when the cooridates are known, it would be helpful for EFE to use them to automatically update the Address, City, State, Post Code, and Country fields.

Regards,
ellispd

Dunno!

KenBushaw wrote:

I haven't heard anything so am wondering if this question got overlooked.

Also, I am wondering why the default line break setting is LF instead of CRLF.
May be a good reason so I would like to know.

Thanks,
Ken

Sorry, but I do not remember. There has to be a reason. Maybe I heard LF was more compatible than CRLF. Dunno.

Try Reverse Geocoding

ellispd wrote:

Turbo,

Would it be possible for EFE to fill in some of the Contact Info fields on the POI Edit window based on the Lat/Lon?

Currently, when a POI is created from a photo the cooridates are written into the Post Code field. I think that when the cooridates are known, it would be helpful for EFE to use them to automatically update the Address, City, State, Post Code, and Country fields.

Regards,
ellispd

You could use the Batch Reverse Geocoding function to do that, but EPE will not set the address field. Reverse Geocoding is very bad. Better than nothing you could say, but very bad in general.

Yes, I could try to implement it and maybe add something in the Preferences to let you decide if you want to add the address field or not.

I will add this to my ToDo list.

Turbo

Why LF?

KenBushaw wrote:

Also, I am wondering why the default line break setting is LF instead of CRLF.
May be a good reason so I would like to know.

The default line break should be LF, not CRLF. The reason being that the text in the Description field of an entry will flow all the way to the end of the screen before moving to the next line. For example, if we use the standard dummy text (Lorem Ipsum) and set EPE line breaks to CRLF, you might get this on your 3.5" Garmin:

"Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor
incididunt ut labore et dolore magna aliqua.
Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip
ex ea commodo consequat. Duis aute irure
dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla
pariatur. Excepteur sint occaecat
cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id
est laborum."

When instead, you wanted this:

"Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum."

In simpler language, a line feed is easier to read than a carriage return with line feed. This is why word processing software automatically line feeds when you get to the end of a line, and only does carriage returns with a line feed when you hit the enter key.

--
"Anyone who is capable of getting themselves made President should on no account be allowed to do the job." --Douglas Adams

Enhancement Request

turboccc wrote:
ellispd wrote:

Turbo,

Would it be possible for EFE to fill in some of the Contact Info fields on the POI Edit window based on the Lat/Lon?

Currently, when a POI is created from a photo the cooridates are written into the Post Code field. I think that when the cooridates are known, it would be helpful for EFE to use them to automatically update the Address, City, State, Post Code, and Country fields.

Regards,
ellispd

You could use the Batch Reverse Geocoding function to do that, but EPE will not set the address field. Reverse Geocoding is very bad. Better than nothing you could say, but very bad in general.

Yes, I could try to implement it and maybe add something in the Preferences to let you decide if you want to add the address field or not.

I will add this to my ToDo list.

Turbo

I hadn't used Batch Reverse Geocoding before. I just tried it and it is a step in the right direction.

Thanks!

CR/LF, etc

I can't remember all of the combinations myself, but there are differences between Garmin units and how they all display line end characters. Maybe LF only works for all?

If you want to experiment, I built a few different types into a test.gpi file that's attached to this faq:
http://www.poi-factory.com/node/21290

--
It's about the Line- If a line can be drawn between the powers granted and the rights retained, it would seem to be the same thing, whether the latter be secured by declaring that they shall not be abridged, or that the former shall not be extended.

I know HTML doesn't work on

I know HTML doesn't work on a nuvi 200W. HTML breaks display the code and don't break. The pipe symbol doesn't work on the 200W either.

The question was why CRLF wasn't the default. I think I explained why I thought LF was better and should be the default. But with all the different GPS units, does CRLF not being the default really matter?

--
"Anyone who is capable of getting themselves made President should on no account be allowed to do the job." --Douglas Adams

Except

Strephon_Alkhalikoi wrote:

I know HTML doesn't work on a nuvi 200W. HTML breaks display the code and don't break. The pipe symbol doesn't work on the 200W either.

Except that wasn't the case when I tried it in a gpx file on my 200W. I'm not sure what sys software version it was running at the time, but I'll check again. See http://www.poi-factory.com/node/21283

Quote:

The question was why CRLF wasn't the default. I think I explained why I thought LF was better and should be the default. But with all the different GPS units, does CRLF not being the default really matter?

Truthfully I hadn't digested all of the possibilities.. rather I thought maybe examples would better serve all the possibilities.

--
It's about the Line- If a line can be drawn between the powers granted and the rights retained, it would seem to be the same thing, whether the latter be secured by declaring that they shall not be abridged, or that the former shall not be extended.

CRLF

I haven't tested this in a long time, but I am on the impression that CRLF is the ONLY way to do a line feed in GPX file on my 760. Again, it has been a long time and I would need to re-test this.

Thanks

Thanks

--
Beechcreek

Original post deleted!

I'm loosing it. Sorry.
But some of you knew that already.
(We need a delete post option.)

--
It's about the Line- If a line can be drawn between the powers granted and the rights retained, it would seem to be the same thing, whether the latter be secured by declaring that they shall not be abridged, or that the former shall not be extended.

My 200W Does Not Like <br>

JD4x4 wrote:

Except that wasn't the case when I tried it in a gpx file on my 200W. I'm not sure what sys software version it was running at the time, but I'll check again. See http://www.poi-factory.com/node/21283

In writing my Historic Ships POI file, I set the breaks to br in EPE and loaded it onto my 200W. Every single br showed up on the address field as well as the description. Very annoying. I had to go back and save the file again with the correct line breaks to get it to look right.

I saw the pics in the thread you mentioned. I'm assuming yours is an original 200W and not one of the rebadged 205W units that were released about a year or so ago for the Christmas holiday?

--
"Anyone who is capable of getting themselves made President should on no account be allowed to do the job." --Douglas Adams

Yes..

Strephon_Alkhalikoi wrote:

..
I saw the pics in the thread you mentioned. I'm assuming yours is an original 200W and not one of the rebadged 205W units that were released about a year or so ago for the Christmas holiday?

Ahh.. yes, it was (is). That must be it. Thanks, good to know. Does the 205W/200W display the comment and description in the order of the older 200W? Just curious.

I had always intended to amend the faq if I ever found out which units behaved similar to the two I used, but I never got enough good feedback to do so. And, I've never gone back to see how the 'newly discovered' 'pipe' chr works on my 765T or 200W.. I should at least do that, I guess.

Sorry you had to re-edit. redface

--
It's about the Line- If a line can be drawn between the powers granted and the rights retained, it would seem to be the same thing, whether the latter be secured by declaring that they shall not be abridged, or that the former shall not be extended.

Units (!)

Ok, two days have passed since my brain was scrambled by this, but I think I have straight what I was trying to post in my deleted message surprised

I've been flipping around editing a gpx file in both EPE v4.84 and MapSource v6.16.2 and having difficulties getting my proximity and speed right when it finally gets to the nuvi.

EPE 'shields' the speed info it writes to the gpx, meaning it takes the speed value and appends a @xx to the POI name. No big deal. But, it converts the speed value in the speed box according to your display & write prefs. Theoretically, no big deal either. EPE also converts the proximity info when it writes the file, if your display pref is different than the write pref. Not a big deal either if you always use EPE.

But..MS literally displays the @xx value in the poi name, AND EXPECTS THE PROX value to be METRIC. At least v6.16.2 seems to.

Now, POILoader on the other hand expects & writes the values in the units that you specify when run.

..Which means, if you create/edit a poi in EPE and compile it with PL then all is lovely. Same if you do it all in MS.

If however, you create it in EPE, throw it into MS for whatever reason & save it, then compile it with PL, your proximity values were saved as metric values but your speed number will be correct if you are expecting Imperial units. (WYSIWYG if you look at the @xx in each poi when in MS).

The bottom line here is watch out!

And, since the Garmin v3 gpx extensions specify Temp, Depth, and Proximity to be metric (meters) ... should EPE do that behind the scenes? To make matters worse, there is no specification or definition for "speed" in the various schemas, so I don't know WHAT to think about the speed conversion in EPE, especially since PoiLoader seems to be 'schema blind'!

I'm pretty sure I got all of this straight, but after two days of saying "What??" I won't swear to it.

Has this been covered before? I'm too dazed to search, apologies.

--
It's about the Line- If a line can be drawn between the powers granted and the rights retained, it would seem to be the same thing, whether the latter be secured by declaring that they shall not be abridged, or that the former shall not be extended.

Hmm

OK, re-reading my post helps further clear this up (to me!).. MS is the problem child, since POILoader expects values in the units you specify, and so does EPE.

Just be aware that if you create a file in MS, your @xx speed number is a 'unitless' value (unconverted), and your proximity will always be saved as metric meters regardless of your prefs in it (MS). Important to know since loading it in EPE will convert both values according to your EPE read prefs.

And vice-versa if you create in EPE and edit with MS. MS leaves the speed number alone, but thinks the prox value is going to be metric meters, converts them for display, and then writes them as metric.

Make sense, or have I also confused EVERYONE besides just me?

--
It's about the Line- If a line can be drawn between the powers granted and the rights retained, it would seem to be the same thing, whether the latter be secured by declaring that they shall not be abridged, or that the former shall not be extended.

Just going through scratching my head this morning re: altitude

I was just looking through my personal POI files wondering why the recorded altitudes were about 1/3 of the actual altitude (feet vs meters). Now I'm glad someone else has seen this as well.... To make things even more comical, I used a 500 foot Tour Guide range in EPE and MapSource is giving me a 1/3 mile proximity... Bleah!

--
Striving to make the NYC Metro area project the best.

Set the Editor preferences

camerabob wrote:

I was just looking through my personal POI files wondering why the recorded altitudes were about 1/3 of the actual altitude (feet vs meters). Now I'm glad someone else has seen this as well.... To make things even more comical, I used a 500 foot Tour Guide range in EPE and MapSource is giving me a 1/3 mile proximity... Bleah!

Under Editor Preferences set the editor to Imperial/US and file read/write to Metric. This allows you to use feet and MPH in creating the file.

--
Illiterate? Write for free help.

Comical... yes!

That's it exactly, comical!

What's the problem.. is it POILoader & EPE not adhering to the gpx 'standard' of meters?

Or, MapSource for being the only one that does??

Well, since POILoader is the last software to touch the file before it becomes a .gpi .... ?

Like I finally figured out, it's really only an issue if you use both EPE and MapSource to tweak the same file. And only then when the last one you use before compiling ISN'T the one you paid close attention to before compiling!

--
It's about the Line- If a line can be drawn between the powers granted and the rights retained, it would seem to be the same thing, whether the latter be secured by declaring that they shall not be abridged, or that the former shall not be extended.

Thanks for that...

Box Car wrote:

Under Editor Preferences set the editor to Imperial/US and file read/write to Metric. This allows you to use feet and MPH in creating the file.

That'll make my life a whole bunch more sane...

--
Striving to make the NYC Metro area project the best.

EPE & units

Guys, try to make things simple for me to understand. I was probably the cause of the problem, but here was my reasoning:

1- EPE used to do open/save in metric only. These were the golden times.

Then, I read similar posts and I imagined that most of you are using the imperial/US system. I figured out you needed to also convert files (like CSV) where you would use only miles and feet; includinh the @XXX speed in the POI name.

2- I added input/output units as well in the Preferences. This would allow you to control the input units, the viewing units in EPE and the output units. This allow as well conversions from Imperial/US to Metric and the opposite. I thought this would simplify everybody's life.

It seems I screwed up everyone. Now, I am a bit reluctant to remove the input/output units because I do not know if anybody is using them. For sure, input/output units in GPX should always be metric. Not sure about units coming from CSV files.

Any thoughts? If you all agree, I do not mind to change things in EPE. After all, I do this for you guys.

Let me know.

Turbo

AFAIK

turboccc wrote:

Guys, try to make things simple for me to understand. I was probably the cause of the problem,

Any thoughts? If you all agree, I do not mind to change things in EPE. After all, I do this for you guys.

Let me know.

Turbo

As far as I know the only value in a CSV is speed and that is set using a combination of the @ symbol and valid values in the file name. I always input the speed camera file and used the Excel formula to add the @ symbol. With the earlier version of the file, speeds were set in some lines, and those without speeds where handled by putting a value in the file name. The file could not be converted to GPX as EPE read the default value and overwrote the value in individual locations. I never bothered to report it as a bug as the workaround was don't use EPE.

--
Illiterate? Write for free help.

Kind of

Box Car wrote:

Under Editor Preferences set the editor to Imperial/US and file read/write to Metric. This allows you to use feet and MPH in creating the file.

Well, that works to an extent but this is where your brain gets really twisted: if you round-trip from EPE to MS and back. All manner of unexpected things happen if you don't remember that

-EPE converts values according to your read prefs, and saves in the format of your Write prefs. EPE also rounds the proximity slightly, MS doesn't.

-MapSource does not manipulate the @xx value (EPE does), and MS expects read values to be metric & writes values as metric.

-POILoader reads and converts @xx and all other values according to your selection when run

..Notice I haven't even thrown in how EPE and MS display all this, or what happens if you forget what final format you saved as when you run POILoader.. shock

--
It's about the Line- If a line can be drawn between the powers granted and the rights retained, it would seem to be the same thing, whether the latter be secured by declaring that they shall not be abridged, or that the former shall not be extended.

@speed value

Are you all in agreement I should not tamper with the @speed in the POI name?

Questions:

1- When reading a CSV file (with the @speed in the POI name), wouldn't you want the speed limit to be converted when saving to a GPX file? Will POILoader use the @speed value in the POI name when loading a GPX file?

2- Would you like EPE to always put the @speed in the POI name when saving to CSV?

3- Any other similar trick I should know about?

Turbo

Turbo...

I'm really on the fence with this discovery about MS, but off the top of my head for now I'd say..

Don't change anything. I'm still digesting a lot of it, and a change to any of the 3 programs mentioned might just make life more unexpected.

I know that now I can at least move forward knowing all this, without any changes.

--
It's about the Line- If a line can be drawn between the powers granted and the rights retained, it would seem to be the same thing, whether the latter be secured by declaring that they shall not be abridged, or that the former shall not be extended.

Yes, about the @xx

turboccc wrote:

..Will POILoader use the @speed value in the POI name when loading a GPX file?..

Yes.

And, everything I've mentioned so far has been in regard to gpx files only. I'm not sure I even want to go near experimenting with csv at my current state of brain mush!

--
It's about the Line- If a line can be drawn between the powers granted and the rights retained, it would seem to be the same thing, whether the latter be secured by declaring that they shall not be abridged, or that the former shall not be extended.

One last thought for now..

Until I get my head straight & experiment a bit more, I think it's important to remember that CSV has no real 'standard' to hold any software to in strict terms. Except the use of commas & quotes, and some sort of line end chr.

GPX on the other hand SHOULD be held to it's schema, and currently that is those values I mentioned should be meters.

But having said that...Garmin's own POILoader (the only thing everyone MUST use (sort of), does NOT appear to care what units are used in a gpx file. Rather it asks the user.

Quick thought is that the real solution is to have EPE read/save gpx values as metric except for @xx in the name, which should not be touched like MS or ask the user what units to use...

BUT ONLY IF POILoader was changed to do the same- i.e. read gpx values as metric (except for @xx values in the name, which it must ask the user about).

OR If MS was changed to ask the user for the gpx read/write units.

So... again I think for now do nothing with how EPE handles gpx files?? MAYBE ask the user if @xx values should be converted for gpx??

--
It's about the Line- If a line can be drawn between the powers granted and the rights retained, it would seem to be the same thing, whether the latter be secured by declaring that they shall not be abridged, or that the former shall not be extended.

What i experienced

turboccc wrote:

Are you all in agreement I should not tamper with the @speed in the POI name?

Questions:

1- When reading a CSV file (with the @speed in the POI name), wouldn't you want the speed limit to be converted when saving to a GPX file? Will POILoader use the @speed value in the POI name when loading a GPX file?

2- Would you like EPE to always put the @speed in the POI name when saving to CSV?

3- Any other similar trick I should know about?

Turbo

Here's what I do with speed values in CSV files.
If a single point has a speed value such as Main at West @45 POILoader will write the value following the @ for this location. If I name the file Enforcement Locations 25.CSV POILoader will read the file and assume all locations have a value of 25 EXCEPT those containing an @ symbol as part of the individual POI. Those locations are set to the value following the @ symbol.

This only works on CSV files. I think, if I remember my testing with EPE several versions ago, is the individual values were replaced with the default value if I tried to convert the CSV to GPX.

--
Illiterate? Write for free help.

EPE and CSV

Just some facts about EPE and CSV:

1- EPE always ignores any numbers in the POI file name. If you want to apply a speed limit to all POI, simply use the Repalce Field function in the Edit menu. This will allow you to make a global replacement of the speed value in all POI.

2- EPE will replace any specific POI name with @speed info by removing the @speed and placing it in the Speed field. It also uses the Input Units as specified in the Preferences to do the conversion.

I will hold on these behaviors for now until a final proposition is agreed upon. For the sake of transparency, EPE should probably keep the @speed in the POI name and not do anything with it. It could also provide a way to convert @speed to Speed field amd Speed field to @speed in POI. That would be an easy thing to do.

Thanks for your comments.

POILoader Behavior

Someone double check this, but it appears that POILoader does expect all GPX (I have NOT tested csv files!) data EXCEPT the @xx value to be in metric.

The POILoader selection of MPH or KPH appears ONLY to convert the @xx values in the POI name.

This means that (I think) EPE needs to write all gpx file values except the @xx as metric. If EPE writes the number after '@' in the filename without changing the value displayed in it's speed box, then the user can run POILoader and select the same units system as EPE displays (Metric/KPH or Imperial/MPH) and the compiled speeds & proximities should work as expected.

And, EPE should expect to read any gpx file as metric, imo. Although maybe you might want to allow a forced Imperial GPX read override since there are now some non-standard gpx files out there?

This is only in regard to gpx files. For now I'll leave EPE's csv speed conversions open for discussion by others. If my brain clears up, I might have an opinion once I can think clearly about it. confused

> Added 8 Sep- > Thinking that the EPE preferences box units drop-down names should be changed from File Read & File Save to CSV File Read & CSV File save. Then you could use a check box someplace that says GPX Imperial Units Input that always defaulted to unchecked?

> Added 8 Sep- > Also thinking that I like the reduced clutter of removing the @xx in the POI name in EPE. If the gpx (only) read/write were hard-coded to only be in metric and you just use the unconverted number in the speed box (as displayed, i.e. in the same Editor units prefs value) when writing gpx, life would be good.

--
It's about the Line- If a line can be drawn between the powers granted and the rights retained, it would seem to be the same thing, whether the latter be secured by declaring that they shall not be abridged, or that the former shall not be extended.

By the way

Even though there is now a .25 mi radius proximity alert around my house that says "Warning! - Insanity Zone" ...

I just wanted to say that EPE is a STELLAR piece of software & TurboCCC has given (and continues to give) the sat-nav community an amazing tool, at a ridiculous price.

Which reminded me that I never 'paid' for my copy. I fixed that just now. Wish I could afford more, Turbo.

--
It's about the Line- If a line can be drawn between the powers granted and the rights retained, it would seem to be the same thing, whether the latter be secured by declaring that they shall not be abridged, or that the former shall not be extended.

Thanks JD4x4

Hi JD4x4,

Thank you very much for this donation. It is very generous of you and it is much appreciated. You helped me also a lot in the past with your comments and suggestions. So thank you again.

Best wishes!

Turbo

Moving right along..

Sorry if my posts about issues switching between MS and EPE confused anyone, but there were some 'fine' points that are now more clear (to me anyway).

The bottom line:

  • An EPE created .gpx file needs to be saved as metric, and compiled with POI Loader using "Meters and KPH" in order for both speed & proximity to compile correctly in the .gpi file.
  • A .gpx file created in MapSource will always have proximity, temp, depth, and altitude saved as metric. Any numbers in the poi name (including those following the @ symbol) are saved as typed and not converted.
  • Both MapSource and POI Loader always read a .gpx file's proximity, temp, depth, and altitude fields as metric.
  • The POI Loader user selection of Feet and MPH or Meters and KPH applies only to numbers in the file name and numbers following the @ symbol in a poi name (and in file name or after @ in the 3rd column of a CSV file).
  • An EPE .gpx file saved as Imperial will not have the correct compiled proximity regardless of POI Loader unit selection.

All of this can be currently worked around, but these bullet points might be helpful in the next EPE Help file.

It might also be helpful if EPE only wrote .gpx files as metric, and in .gpx files (only) it saved the number shown in the Speed box after the @ symbol. - That way a user could match POI Loader's units selection to EPE's display prefs, and since the saved .gpx (except after@) was metric as PL expects, both speed & prox would be right when compiled.

--
It's about the Line- If a line can be drawn between the powers granted and the rights retained, it would seem to be the same thing, whether the latter be secured by declaring that they shall not be abridged, or that the former shall not be extended.

That jives

JD4x4 wrote:

Sorry if my posts about issues switching between MS and EPE confused anyone, but there were some 'fine' points that are now more clear (to me anyway).

The bottom line:

  • An EPE created .gpx file needs to be saved as metric,
  • A .gpx file created in MapSource will always have proximity, temp, depth, and altitude saved as metric. Any numbers in the poi name (including those following the @ symbol) are saved as typed and not converted.
  • Both MapSource and POI Loader always read a .gpx file's proximity, temp, depth, and altitude fields as metric.
  • The POI Loader user selection of Feet and MPH or Meters and KPH applies only to numbers in the file name and numbers following the @ symbol
  • An EPE .gpx file saved as Imperial will not have the correct compiled proximity regardless of POI Loader unit selection.

All of this can be currently worked around, but these bullet points might be helpful in the next EPE Help file.

Thanks JD.

This jives with what I and others have found by experience - at least as far as EPE. I don't use MS much, I find it difficult to work with as it is not as configurable as other programs, so I use it as a last resort.

--
Illiterate? Write for free help.

Only recently

I've only recently noticed issues with my proximities..just because I never looked. My alerts worked 'funky' sometimes, but I never took a close enough look once they were on the unit to see that either my speeds were wacked or my proximities were!

I use MS because it shows the TourGuide radius as a red ring around the poi and it makes it nice for 'tweaking' them. That and creating routes. Otherwise I use EPE for the most part, and my Excel gpx/csv converter to do bulk edits.

By the way, the gpx files seem to work the same way you were describing the csv for default speed, in case you weren't aware. Meaning a number in the file name becomes the default speed if a poi doesn't have the @nn in it's name.

..And, thank YOU for confirming that I finally got it right! For a while I was seriously confused!!

--
It's about the Line- If a line can be drawn between the powers granted and the rights retained, it would seem to be the same thing, whether the latter be secured by declaring that they shall not be abridged, or that the former shall not be extended.

Let's recap

I got the easy parts:

1- GPX read and write should be in Metric.
2- All @speed from GPX should be Metric.
3- I will remove the automation that extracts the @speed from the POI name and leave it untouched in the POI name.

Am I good so far?

4- I will rename the File Read/Write Units Preferences to be "CSV File Read" and "CSV File Write". So, only CSV file will have control over the Read/Write units.

Almost perfect?

turboccc wrote:

I got the easy parts:

1- GPX read and write should be in Metric.

Well.. Write should be, but maybe allow read in Imperial for those non-std cases? I'd see what the other users say??

Quote:

2- All @speed from GPX should be Metric.

Well, in MS and POI Loader they are 'unitless'..just numbers after the@ symbol in the poi name.

Quote:

3- I will remove the automation that extracts the @speed from the POI name and leave it untouched in the POI name.

That's totally up to you, since I sort of like it being shown in the Speed box, and removed from the name when looking at a record. Converting it and putting it in the box with the user's display preferences isn't as big a problem as converting it to the write format when it's written. If it's written metric (actually it can't be metric-it's unitless) & the user compiles in PL as metric it works. But if it's say, 10 and a user's speed box says mph, if the rest of the fields are metric then choosing Mph in PL will still compile as mph. Does that make sense?

Quote:

Am I good so far?

4- I will rename the File Read/Write Units Preferences to be "CSV File Read" and "CSV File Write". So, only CSV file will have control over the Read/Write units.

Makes sense to me. And, if you allow gpx to be read as Imperial (your choice) you could just have a Imperial gpx Read toggle. Just a thought.

The only reason to allow Imperial gpx read is to get a prior version EPE-created (or other?) non-standard gpx file in to EPE. Once in it should write as metric.

I don't know if there is anyone else out there that might need to read a non-std gpx.

--
It's about the Line- If a line can be drawn between the powers granted and the rights retained, it would seem to be the same thing, whether the latter be secured by declaring that they shall not be abridged, or that the former shall not be extended.

Auto save

Would it take much to add an auto-save function to the already excellent EPE? e.g. Every 15 minutes or so it would write any changes back to the file that is open so in case something goes wrong, the most one would be out is the last 15 minutes of work. This could be selected by the user if they wanted it turned on or not.

In the meantime, I'll set a kitchen timer to remind me to do a save. Time flies when you're really into updating a file and when the lights go out and you discover the ups has a bad battery....

--
"There's no substitute for local knowledge" nüvi 750, nüvi 3597

Agree

EPE is great but an autosave feature would be nice. Thanks for all the improvements to EPE. You're doing a fantastic job.

--
Nuvi 750 and 755T

Thank You

EPE is still amazing and getting better all of the time. Thank you.

Additional thought on auto-save

TXRVer wrote:

...Every 15 minutes or so it would write any changes back to the file that is open so in case something goes wrong, the most one would be out is the last 15 minutes of work...

After a night's sleep, I thought that rather than writing it back directly to the open file, maybe better to a copy of the open file so as not to alter the working copy. Then when finished, a normal save or save as will make all the changes to the open file and the user could simply delete the copy. Should the PC get zapped during the process, the copy could be inspected and then manually replace the original and work could resume where the last good entry had been made. Again no more than 15 minutes lost work.

--
"There's no substitute for local knowledge" nüvi 750, nüvi 3597

Auto-Save

I am glad you do not want to save to the currently open file anymore. Much harder than it seeems when files have been merged or you have a multi-column CSV with merged fields, etc... Very hard to save to the original format without losing anything.

I propose to save to a 'last_open_file.gpx' (for example) in the EPE folder. This way, you know its name and its location. It will be a GPX so you will not lose any data and it makes it easy to convert it to anything else afterward.

What do you think?

Not last open - unless

turboccc wrote:

I am glad you do not want to save to the currently open file anymore. Much harder than it seeems when files have been merged or you have a multi-column CSV with merged fields, etc... Very hard to save to the original format without losing anything.

I propose to save to a 'last_open_file.gpx' (for example) in the EPE folder. This way, you know its name and its location. It will be a GPX so you will not lose any data and it makes it easy to convert it to anything else afterward.

What do you think?

I'm not sure about the "last open" as when trying to merge one or more files. As an example you open several state or provincial file to merge them into a file with a different final output name. Perhaps some convention such as temp~.gpx would work. It would be easy to search for and a known file to delete when closing EPE.

--
Illiterate? Write for free help.

Auto-Save

Why not "EPE_auto_save.gpx" ? I thin having EPE in it makes it easier to figure which program made the temps file.

no problems with that name

turboccc wrote:

Why not "EPE_auto_save.gpx" ? I thin having EPE in it makes it easier to figure which program made the temps file.

As long as when you do a save it will erase any temp file written to the computer. Another option, if you have a crash due to stupidity, will there be an "open recovery file option"? How about if you find your temp file you ask if it should be opened? That makes recovery optional.

--
Illiterate? Write for free help.
1 2 3
5 6 7 8 ... 13
<<Page 4>>