APRSISCE@groups.io | Minor details.

James Ewen

#481

Lynn,

Thanks for creating what sounds like it might just become the top APRS
client in the future. We've had a progression of APRS applications
over the years, with each one moving the bar higher and higher. Having
an author responsive to the needs and desires of the users is a major
factor in developing a great application.

Now... onto the nitty gritty bits.

Right off the top, have you thought about renaming the program?
Obviously the name reflects the origins of the program, but it looks
to be headed to be much more than that.

I finally had a look at the program just over a week ago... I hadn't
looked before because of the name, assuming it was for Windows Mobile
devices only. I'd suggest not only dropping the CE portion, but also
the APRSIS portion. The APRS-IS name is the Internet Service portion
of the APRS network. This client appears to be moving beyond that, and
encompassing the RF portion as well. Perhaps a new less limiting name
might be in order... a really sexy or cool name for the application
never hurt.

Can you make it so that the large compass face can be a user
selectable display element? I would like to get rid of the big grey
circle and NESW labels on my screen.

I love the fact that you use the OSM map in this application. I've
been helping that project for a couple years now. It is great that
anyone can add detail to the OSM map. Any missing data can easily be
added, and immediately becomes available worldwide! One issue that I
have however is the way that the tiles are saved to the hard drive.

I use a program called RadioMobile that also uses the OSM tiles for
creating a background map. RadioMobile saves the tiles in almost the
exact same way as APRSIS32, but with  just a slight naming difference.
APRSIS32 uses a file structure such as OSM12/748/1334.png whereas
RadioMobile saves the exact same tile under the file structure
12/748/1334.png

It would be very desirable to share the tiles across multiple
platforms, rather than have duplicate tiles saved for each
application. I don't know if there's an "official" file naming
structure defined for saving OSM tiles, but if it was possible to
override the naming structure to allow the two programs to match up,
it would be great. All I would need to be able to do, is to have the
OSMXX structure changed to just XX where XX is the zoom level.

James
VE6SRV

Fred Hillhouse

#494

Hi James,

You make valid points. I only really looked at this software after a response to Stephen about the ability to tile save. So it is new to me as well. Nice slick package so far!

Maybe a sexy name contest is in order. ;)

I found the tile collection is an interesting item. While I don’t use anything else that uses the OSM tiles it is a bone of contention for me. I started using ExpertGPS about 10 years ago. And I have thousands of tiles saved of the topo, aerial and urban variety. I messed around with USAPhotomaps as well. I really didn’t want to dedicate another large portion to the same tile set. I looked at TopoFusion as well. That was the end of that; another tile collection. I stuck with E-GPS. I can’t say I went wrong, it is a great package.

Best regards,

Fred

From: aprsisce@... [mailto:aprsisce@...] On Behalf Of James Ewen
Sent: Sunday, February 28, 2010 2:42 AM
To: aprsisce@...
Subject: [aprsisce] Minor details.

Lynn,

Thanks for creating what sounds like it might just become the top APRS
client in the future. We've had a progression of APRS applications
over the years, with each one moving the bar higher and higher. Having
an author responsive to the needs and desires of the users is a major
factor in developing a great application.

Now... onto the nitty gritty bits.

Right off the top, have you thought about renaming the program?
Obviously the name reflects the origins of the program, but it looks
to be headed to be much more than that.

I finally had a look at the program just over a week ago... I hadn't
looked before because of the name, assuming it was for Windows Mobile
devices only. I'd suggest not only dropping the CE portion, but also
the APRSIS portion. The APRS-IS name is the Internet Service portion
of the APRS network. This client appears to be moving beyond that, and
encompassing the RF portion as well. Perhaps a new less limiting name
might be in order... a really sexy or cool name for the application
never hurt.

Can you make it so that the large compass face can be a user
selectable display element? I would like to get rid of the big grey
circle and NESW labels on my screen.

I love the fact that you use the OSM map in this application. I've
been helping that project for a couple years now. It is great that
anyone can add detail to the OSM map. Any missing data can easily be
added, and immediately becomes available worldwide! One issue that I
have however is the way that the tiles are saved to the hard drive.

I use a program called RadioMobile that also uses the OSM tiles for
creating a background map. RadioMobile saves the tiles in almost the
exact same way as APRSIS32, but with just a slight naming difference.
APRSIS32 uses a file structure such as OSM12/748/1334.png whereas
RadioMobile saves the exact same tile under the file structure
12/748/1334.png

It would be very desirable to share the tiles across multiple
platforms, rather than have duplicate tiles saved for each
application. I don't know if there's an "official" file naming
structure defined for saving OSM tiles, but if it was possible to
override the naming structure to allow the two programs to match up,
it would be great. All I would need to be able to do, is to have the
OSMXX structure changed to just XX where XX is the zoom level.

James
VE6SRV

Lynn Deffenbaugh

#495

Fred Hillhouse Jr wrote:

You make valid points. I only really looked at this software after a response to Stephen about the ability to tile save. So it is new to me as well. Nice slick package so far!
The primary design for APRSISCE is for operation on mobile devices with an active Internet connection. I consider it secondary operation to work without APRS-IS (and hence OSM) access. If the primary function was for offline use, the tile prefetching is actually a pre-population of the cache used to buffer recently accessed tiles.

Maybe a sexy name contest is in order. ;)
Got a suggestion, I'll consider it, although APRSISCE/32 isn't that bad, is it?

I found the tile collection is an interesting item. While I dont use anything else that uses the OSM tiles it is a bone of contention for me. I started using ExpertGPS about 10 years ago. And I have thousands of tiles saved of the topo, aerial and urban variety. I messed around with USAPhotomaps as well. I really didnt want to dedicate another large portion to the same tile set. I looked at TopoFusion as well. That was the end of that; another tile collection. I stuck with E-GPS. I cant say I went wrong, it is a great package.
Can you provide links to the packages you mention. I googled E-GPS, but didn't find any references in the top hits that implied tile caching.

Depending on what tiles they install and/or maintain, you MIGHT be able to share a directory tree between them and APRSISCE.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32


Best regards,

Fred

------------------------------------------------------------------------

*From:* aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com] *On Behalf Of *James Ewen
*Sent:* Sunday, February 28, 2010 2:42 AM
*To:* aprsisce@yahoogroups.com
*Subject:* [aprsisce] Minor details.

Lynn,

Thanks for creating what sounds like it might just become the top APRS
client in the future. We've had a progression of APRS applications
over the years, with each one moving the bar higher and higher. Having
an author responsive to the needs and desires of the users is a major
factor in developing a great application.

Now... onto the nitty gritty bits.

Right off the top, have you thought about renaming the program?
Obviously the name reflects the origins of the program, but it looks
to be headed to be much more than that.

I finally had a look at the program just over a week ago... I hadn't
looked before because of the name, assuming it was for Windows Mobile
devices only. I'd suggest not only dropping the CE portion, but also
the APRSIS portion. The APRS-IS name is the Internet Service portion
of the APRS network. This client appears to be moving beyond that, and
encompassing the RF portion as well. Perhaps a new less limiting name
might be in order... a really sexy or cool name for the application
never hurt.

Can you make it so that the large compass face can be a user
selectable display element? I would like to get rid of the big grey
circle and NESW labels on my screen.

I love the fact that you use the OSM map in this application. I've
been helping that project for a couple years now. It is great that
anyone can add detail to the OSM map. Any missing data can easily be
added, and immediately becomes available worldwide! One issue that I
have however is the way that the tiles are saved to the hard drive.

I use a program called RadioMobile that also uses the OSM tiles for
creating a background map. RadioMobile saves the tiles in almost the
exact same way as APRSIS32, but with just a slight naming difference.
APRSIS32 uses a file structure such as OSM12/748/1334.png whereas
RadioMobile saves the exact same tile under the file structure
12/748/1334.png

It would be very desirable to share the tiles across multiple
platforms, rather than have duplicate tiles saved for each
application. I don't know if there's an "official" file naming
structure defined for saving OSM tiles, but if it was possible to
override the naming structure to allow the two programs to match up,
it would be great. All I would need to be able to do, is to have the
OSMXX structure changed to just XX where XX is the zoom level.

James
VE6SRV

g4ilo

#500

--- In aprsisce@yahoogroups.com, "Lynn W. Deffenbaugh" <kj4erj@...> wrote:

Maybe a sexy name contest is in order. ;)
Got a suggestion, I'll consider it, although APRSISCE/32 isn't that bad,
is it?How about APRSXE (APRS - Sexy)? :)

Fred Hillhouse

#503

I found the tile collection is an interesting item. While I don't use 
anything else that uses the OSM tiles it is a bone of contention for 
me. I started using ExpertGPS about 10 years ago. And I have thousands 
of tiles saved of the topo, aerial and urban variety. I messed around 
with USAPhotomaps as well. I really didn't want to dedicate another 
large portion to the same tile set. I looked at TopoFusion as well.
That was the end of that; another tile collection. I stuck with E-GPS. 
I can't say I went wrong, it is a great package.
Can you provide links to the packages you mention. I googled E-GPS, but 
didn't find any references in the top hits that implied tile caching.

Depending on what tiles they install and/or maintain, you MIGHT be able 
to share a directory tree between them and APRSISCE.

Hi Lynn,

Sorry, I didn't mean to imply that ExpertGPS uses the OSM tiles.

James had mentioned that RadioMobile does use the OSM tile set and the file
structure is almost the same. At least that is the way I understood his
comments. And I have not researched RadioMobile so I have no comment
regarding it. I think the point is that standardizing the way the tiles are
saved would be handy. In an ideal situation, the filenames would be same as
what is served up and in the same tree structure.

This was James comments for quick referral:
"I use a program called RadioMobile that also uses the OSM tiles for
creating a background map. RadioMobile saves the tiles in almost the
exact same way as APRSIS32, but with just a slight naming difference.
APRSIS32 uses a file structure such as OSM12/748/1334.png whereas
RadioMobile saves the exact same tile under the file structure
12/748/1334.png."

I notice this in the XML:
<OSM.Path>d:&#92;APRSISCE&#92;OSMTiles&#92;</OSM.Path>

Maybe James can edit this line to support RadioMobile and APRSISCE?

----

The program I mentioned, ExpertGPS, can be found here:
http://www.expertgps.com/

I use "E-GPS" for short. I have the GIS/CAD version.

It uses the Teraserver tile set. My point was that in the software world
that is using the USGS tile sets, everyone has a different way to file and
use. Case in point: the USAPhotoMap implementation is totally different when
compared with the E-GPS implementation. It requires twice the download if
the same tileset is used for each package.

My ExpertGPS topographic and aerial tile collection (USGS Tiles/Teraserver)
is a good size.
Type 1 (aerial) 3.79GB on disk in 442,587 Files, 72 Folders.
Type 2 (topo) 5.18GB on disk in 350,089 Files, 65 Folders.
Type 4 (urban) 68.2MB on disk in 11,488 files, 26 folders.

It is a part of the software from: http://www.topografix.com/
There have a nifty free GPS management package called EasyGPS:
http://www.easygps.com/ (no mapping)
For those that Geocache: http://www.geobuddy.com/

BTW, the E-GPS author was the designer of the GPX format or at least very
much involved.
http://www.topografix.com/gpx.asp

Dan Foster is another author that has been very responsive to his customers.
That is one reason I stay with TopoGrafix.

For APRS, I will stay with your software even though the mobile market is
your main goal. Everything I see so far is good. First off, you are
responsive. This doesn't mean you add everything people want but that you
are addressing items on a regular basis and provide answers. Second, the
software is expanding. I can only imagine where APRSISCE is heading. And, of
course we all have our desires. ;)

Thanks again!!


Best regards,
Fred

Charles Doughtie

#504

--- On Mon, 3/1/10, g4ilo wrote:

From: g4ilo
Subject: [aprsisce] Re: Minor details.
To: aprsisce@...
Date: Monday, March 1, 2010, 4:11 AM

--- In aprsisce@yahoogroup s.com, "Lynn W. Deffenbaugh" wrote:

> > Maybe a sexy name contest is in order. ;)
> >
>
> Got a suggestion, I'll consider it, although APRSISCE/32 isn't that bad,
> is it?

How about APRSXE (APRS - Sexy)? :)

Sounds neat to me - -
de N5exy

Fred Hillhouse

#506

Is your call sign NSEXY?

;)

Show quoted text

From: aprsisce@... [mailto:aprsisce@...] On Behalf Of Charles Doughtie
Sent: Monday, March 01, 2010 10:29
To: aprsisce@...
Subject: Re: [aprsisce] Re: Minor details.

--- On Mon, 3/1/10, g4ilo gmail.com> wrote:

From: g4ilo gmail.com>
Subject: [aprsisce] Re: Minor details.
To: aprsisce@yahoogroups.com
Date: Monday, March 1, 2010, 4:11 AM

--- In aprsisce@yahoogroup s.com, "Lynn W. Deffenbaugh" wrote:

> > Maybe a sexy name contest is in order. ;)
> >
>
> Got a suggestion, I'll consider it, although APRSISCE/32 isn't that bad,
> is it?

How about APRSXE (APRS - Sexy)? :)

Sounds neat to me - -

de N5exy

Charles Doughtie

#507

With a 5, not S. My license plates draw some strange comments.

Callsign	Name	Address
E	KA5EXY	PATTAN, THELMA L	3911 N RIVER RD, PORT ALLEN, LA 70767
A	KB5EXY	NATHANSON, DAVID L	902 W Glendale Unit 201, PHOENIX, AZ 85021
A	KC5EXY	DENSON, JOHN G	PO Box 946, BELMONT, MS 38827
A	KD5EXY	Huff, Richard C	220 Rainbow Dr PMB 12001, Livingston, TX 773519362
A	N5EXY	DOUGHTIE, CHARLES T	PO Box 24, AUSTIN, TX 78767
C	W5EXY	KANZ, HANNO E	296 N UNION AVE, NEW BRAUNFELS, TX 781304450
A	WA5EXY	HEDRICK, ALAN C	HR 3 BOX 2A, HOOKER, OK 73945
A	WB5EXY	ALEXANDER, ROBERT T	706 ROMAINE LN, HOUSTON, TX 77090
A	WD5EXY	MC MULLIN, WILLIAM J	2011 HUNTINGTON, OKLAHOMA CITY, OK 73116
A	W5EXY	Sergeant, Julian D	539 S 12th Street, Port Aransas, TX 78373
C	KE5EXY	Burton, Matthew R	PO Box 833, Bixby, OK 74008
A	KF5EXY	Abdulhussain, Mansur	10924 Grant Rd, Houston, TX 77070

New Search

Show quoted text

--- On Mon, 3/1/10, Fred Hillhouse wrote:

From: Fred Hillhouse
Subject: RE: [aprsisce] Re: Minor details.
To: aprsisce@...
Date: Monday, March 1, 2010, 9:54 AM

Is your call sign NSEXY?

;)

From: aprsisce@yahoogroup s.com [mailto:aprsisce@ yahoogroups. com] On Behalf Of Charles Doughtie
Sent: Monday, March 01, 2010 10:29
To: aprsisce@yahoogroup s.com
Subject: Re: [aprsisce] Re: Minor details.

--- On Mon, 3/1/10, g4ilo wrote:

From: g4ilo Subject: [aprsisce] Re: Minor details.
To: aprsisce@yahoogroup s.com
Date: Monday, March 1, 2010, 4:11 AM

--- In aprsisce@yahoogroup s.com, "Lynn W. Deffenbaugh" wrote:

> > Maybe a sexy name contest is in order. ;)
> >
>
> Got a suggestion, I'll consider it, although APRSISCE/32 isn't that bad,
> is it?

How about APRSXE (APRS - Sexy)? :)

Sounds neat to me - -

de N5exy

Lynn Deffenbaugh

#513

Fred Hillhouse wrote:

This was James comments for quick referral:
"I use a program called RadioMobile that also uses the OSM tiles for
creating a background map. RadioMobile saves the tiles in almost the
exact same way as APRSIS32, but with just a slight naming difference.
APRSIS32 uses a file structure such as OSM12/748/1334.png whereas
RadioMobile saves the exact same tile under the file structure
12/748/1334.png."

I notice this in the XML:
<OSM.Path>d:&#92;APRSISCE&#92;OSMTiles&#92;</OSM.Path>

Maybe James can edit this line to support RadioMobile and APRSISCE?
  If James sould just put a &#92; at the end of his OSM.Path, he would find that the file structures are identical.  However, if you point APRSISCE/32 to the same directory as another program, be aware that tiles will be fetched and purged as if they were owned by APRSISCE/32.  This may or may not be desired behavior.  The tile naming and directory structure are documented at http://wiki.openstreetmap.org/wiki/Slippy_map_tilenames.

Lynn (D) - KJ4ERJ

Fred Hillhouse

#518

--- In aprsisce@yahoogroups.com, "Lynn W. Deffenbaugh" <kj4erj@...> wrote:

Fred Hillhouse wrote:

This was James comments for quick referral:
"I use a program called RadioMobile that also uses the OSM tiles for
creating a background map. RadioMobile saves the tiles in almost the
exact same way as APRSIS32, but with just a slight naming difference.
APRSIS32 uses a file structure such as OSM12/748/1334.png whereas
RadioMobile saves the exact same tile under the file structure
12/748/1334.png."

I notice this in the XML:
<OSM.Path>d:&#92;APRSISCE&#92;OSMTiles&#92;</OSM.Path>

Maybe James can edit this line to support RadioMobile and APRSISCE?
If James sould just put a &#92; at the end of his OSM.Path, he would find
that the file structures are identical.  However, if you point
APRSISCE/32 to the same directory as another program, be aware that
tiles will be fetched and purged as if they were owned by APRSISCE/32.
This may or may not be desired behavior.  The tile naming and directory
structure are documented at
http://wiki.openstreetmap.org/wiki/Slippy_map_tilenames.

Lynn (D) - KJ4ERJ
Of course the XML can be changed to disable purging. I did that for myself just so the tiles stay.

Best regards,
Fred

Fred Hillhouse

#523

--- In aprsisce@yahoogroups.com, "g4ilo" <julian.g4ilo@...> wrote:



--- In aprsisce@yahoogroups.com, "Lynn W. Deffenbaugh" <kj4erj@> wrote:

Maybe a sexy name contest is in order. ;)
Got a suggestion, I'll consider it, although APRSISCE/32 isn't that bad,
is it?How about APRSXE (APRS - Sexy)? :)
Works for me!

James Ewen

#531

On Mon, Mar 1, 2010 at 3:39 PM, Lynn W. Deffenbaugh <kj4erj@arrl.net> wrote:

I notice this in the XML:
<OSM.Path>d:&#92;APRSISCE&#92;OSMTiles&#92;</OSM.Path>

Maybe James can edit this line to support RadioMobile and APRSISCE?
If James sould just put a &#92; at the end of his OSM.Path, he would find
that the file structures are identical.That would be cool... I'm just not sure how I get the two to match up...

Here's my path qualifier:

<OSM.Path>C:&#92;Documents and Settings&#92;jame&#92;My Documents&#92;RadioMobile
Data&#92;OSM&#92;OSMTiles&#92;</OSM.Path>

And here's the tile at zoom level 13 that has my house on it.

C:&#92;Documents and Settings&#92;jame&#92;My Documents&#92;RadioMobile Data&#92;OSM13&#92;1518&#92;2648.png

RadioMobile stores the same tile as:

C:&#92;Documents and Settings&#92;jame&#92;My Documents&#92;RadioMobile
Data&#92;OSM&#92;13&#92;1518&#92;2648.png

Note that one pesky slash between the OSM and 13...

It looks like APRSISCE replaces the OSM in it's path qualifier with
OSMxx where xx is the zoom level, and the OSMTiles is replaced by the
X value, and the Y value is the name of the tile...

So where do I put the slash at the end of to get APRSISCE to not use
the OSMxx zoom level folder name format, but just use xx as the zoom
level folder name?

 However, if you point
APRSISCE/32 to the same directory as another program, be aware that
tiles will be fetched and purged as if they were owned by APRSISCE/32.
This may or may not be desired behavior.Overriding purging is the answer to that issue... however that brings
up another question. Can you force a fetch of tiles in an area? The
OSM map is constantly in flux as new information is added. With
RadioMobile, I kept a large cache of tiles available. However when new
tiles became available in an area, I would have to manually delete the
tiles in that area. Obviously not an easy thing to do manually, so
wholesale deletion was the simple solution. This of course means that
all of the tiles need to be fetched again. When you are talking about
gigabytes of tiles, that can be a very long task. Being able to keep
the majority of tiles, and only fetching ones  selected by the user
would be a good thing.

Obviously automatic purging ensures that tiles stay up to date, but
that doesn't help those who want to use the program in an offline mode
with large tile caches.

James
VE6SRV

Lynn Deffenbaugh

#538

James Ewen wrote:
On Mon, Mar 1, 2010 at 3:39 PM, Lynn W. Deffenbaugh <kj4erj@arrl.net> wrote:

  
If James sould just put a &#92; at the end of his OSM.Path, he would find
that the file structures are identical.
    That would be cool... I'm just not sure how I get the two to match up...

Here's my path qualifier:

<OSM.Path>C:&#92;Documents and Settings&#92;jame&#92;My Documents&#92;RadioMobile
Data&#92;OSM&#92;OSMTiles&#92;</OSM.Path>

And here's the tile at zoom level 13 that has my house on it.

C:&#92;Documents and Settings&#92;jame&#92;My Documents&#92;RadioMobile Data&#92;OSM13&#92;1518&#92;2648.png
  Edit the XML file (http://aprsisce.wikidot.com/editing-xml-configuration) and remove the OSMTiles&#92; from the end of the list, so that the OSM.Path ednds in ...Data&#92;OSM&#92;

RadioMobile stores the same tile as:

C:&#92;Documents and Settings&#92;jame&#92;My Documents&#92;RadioMobile
Data&#92;OSM&#92;13&#92;1518&#92;2648.png

Note that one pesky slash between the OSM and 13...
  Actually, I thought it was RadioMobile that didn't have the slash.  See if the above change works.


 However, if you point
APRSISCE/32 to the same directory as another program, be aware that
tiles will be fetched and purged as if they were owned by APRSISCE/32.
This may or may not be desired behavior.
    Overriding purging is the answer to that issue... however that brings
up another question. Can you force a fetch of tiles in an area? The
OSM map is constantly in flux as new information is added. With
RadioMobile, I kept a large cache of tiles available. However when new
tiles became available in an area, I would have to manually delete the
tiles in that area. Obviously not an easy thing to do manually, so
wholesale deletion was the simple solution. This of course means that
all of the tiles need to be fetched again. When you are talking about
gigabytes of tiles, that can be a very long task. Being able to keep
the majority of tiles, and only fetching ones  selected by the user
would be a good thing.
  I've got items on the ToDo list to "freshen" tiles.  OSM's tile servers have a feature where you can ask it for the tile's revision.  I'm hoping to use that in conjuction with dates stored on the tile files to detect the changes automatically (or when told to check for offline users) and download only those tiles that indicate changes.

Obviously automatic purging ensures that tiles stay up to date, but
that doesn't help those who want to use the program in an offline mode
with large tile caches.
  I'm striving to make it work well in both modes.  I finally got my son, KJ4DXK, to start using APRSIS32 and he's totally an off-line user.  When he finishes, APRSIS32 will be an optional viewer and messaging platform for his home-brew, in-car APRS system (KJ4DXK-9).

Lynn (D) - KJ4ERJ -


James
VE6SRV


------------------------------------

Yahoo! Groups Links

Colin Catlin <m6xsd@...>

#539

Lynn wrote:

>I'm striving to make it work well in both modes. I finally got my son,
>KJ4DXK, to start using APRSIS32 and he's totally an off-line user. When
>he finishes, APRSIS32 will be an optional viewer and messaging platform
>for his home-brew, in-car APRS system (KJ4DXK-9).

It would be great if your son could keep us informed about his home-brew and how he is using APRSIS32 with itJ

73,

Colin.

-----Original Message-----

Show quoted text

From: aprsisce@... [mailto:aprsisce@...] On Behalf Of Lynn W. Deffenbaugh
Sent: 02 March 2010 12:56
To: aprsisce@...
Subject: Re: [aprsisce] Minor details.

James Ewen wrote:
> On Mon, Mar 1, 2010 at 3:39 PM, Lynn W. Deffenbaugh <kj4erj@arrl.net> wrote:
>
>
>> If James sould just put a \ at the end of his OSM.Path, he would find
>> that the file structures are identical.
>>
>
> That would be cool... I'm just not sure how I get the two to match up...
>
> Here's my path qualifier:
>
> C:\Documents and Settings\jame\My Documents\RadioMobile
> Data\OSM\OSMTiles\
>
> And here's the tile at zoom level 13 that has my house on it.
>
> C:\Documents and Settings\jame\My Documents\RadioMobile Data\OSM13\1518\2648.png
>

Edit the XML file
(http://aprsisce.wikidot.com/editing-xml-configuration) and remove the
OSMTiles\ from the end of the list, so that the OSM.Path ednds in
...Data\OSM\

> RadioMobile stores the same tile as:
>
> C:\Documents and Settings\jame\My Documents\RadioMobile
> Data\OSM\13\1518\2648.png
>
> Note that one pesky slash between the OSM and 13...
>

Actually, I thought it was RadioMobile that didn't have the slash. See
if the above change works.

>> However, if you point
>> APRSISCE/32 to the same directory as another program, be aware that
>> tiles will be fetched and purged as if they were owned by APRSISCE/32.
>> This may or may not be desired behavior.
>>
>
> Overriding purging is the answer to that issue... however that brings
> up another question. Can you force a fetch of tiles in an area? The
> OSM map is constantly in flux as new information is added. With
> RadioMobile, I kept a large cache of tiles available. However when new
> tiles became available in an area, I would have to manually delete the
> tiles in that area. Obviously not an easy thing to do manually, so
> wholesale deletion was the simple solution. This of course means that
> all of the tiles need to be fetched again. When you are talking about
> gigabytes of tiles, that can be a very long task. Being able to keep
> the majority of tiles, and only fetching ones selected by the user
> would be a good thing.
>

I've got items on the ToDo list to "freshen" tiles. OSM's tile servers
have a feature where you can ask it for the tile's revision. I'm hoping
to use that in conjuction with dates stored on the tile files to detect
the changes automatically (or when told to check for offline users) and
download only those tiles that indicate changes.

> Obviously automatic purging ensures that tiles stay up to date, but
> that doesn't help those who want to use the program in an offline mode
> with large tile caches.
>

I'm striving to make it work well in both modes. I finally got my son,
KJ4DXK, to start using APRSIS32 and he's totally an off-line user. When
he finishes, APRSIS32 will be an optional viewer and messaging platform
for his home-brew, in-car APRS system (KJ4DXK-9).

Lynn (D) - KJ4ERJ -

> James
> VE6SRV
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>

m6xsd <m6xsd@...>

#549

Hi Again Lynn,

I've been giving the issue of alternative mapping a bit more thought and wondered if you could implement an 'alternative set of tiles' that could be stored in an alternative location and toggled somehow. And if the required tile isn't found in the 'currently preferred' location then the other location is temporarily used (with a suitable indication on the screen.

73,
Colin.

Show quoted text

--- In aprsisce@yahoogroups.com, "Lynn W. Deffenbaugh" <kj4erj@...> wrote:

James Ewen wrote:
On Mon, Mar 1, 2010 at 3:39 PM, Lynn W. Deffenbaugh <kj4erj@...> wrote:


If James sould just put a &#92; at the end of his OSM.Path, he would find
that the file structures are identical.
That would be cool... I'm just not sure how I get the two to match up...

Here's my path qualifier:

<OSM.Path>C:&#92;Documents and Settings&#92;jame&#92;My Documents&#92;RadioMobile
Data&#92;OSM&#92;OSMTiles&#92;</OSM.Path>

And here's the tile at zoom level 13 that has my house on it.

C:&#92;Documents and Settings&#92;jame&#92;My Documents&#92;RadioMobile Data&#92;OSM13&#92;1518&#92;2648.png
Edit the XML file
(http://aprsisce.wikidot.com/editing-xml-configuration) and remove the
OSMTiles&#92; from the end of the list, so that the OSM.Path ednds in
...Data&#92;OSM&#92;

RadioMobile stores the same tile as:

C:&#92;Documents and Settings&#92;jame&#92;My Documents&#92;RadioMobile
Data&#92;OSM&#92;13&#92;1518&#92;2648.png

Note that one pesky slash between the OSM and 13...
Actually, I thought it was RadioMobile that didn't have the slash.  See
if the above change works.


 However, if you point
APRSISCE/32 to the same directory as another program, be aware that
tiles will be fetched and purged as if they were owned by APRSISCE/32.
This may or may not be desired behavior.
Overriding purging is the answer to that issue... however that brings
up another question. Can you force a fetch of tiles in an area? The
OSM map is constantly in flux as new information is added. With
RadioMobile, I kept a large cache of tiles available. However when new
tiles became available in an area, I would have to manually delete the
tiles in that area. Obviously not an easy thing to do manually, so
wholesale deletion was the simple solution. This of course means that
all of the tiles need to be fetched again. When you are talking about
gigabytes of tiles, that can be a very long task. Being able to keep
the majority of tiles, and only fetching ones  selected by the user
would be a good thing.
I've got items on the ToDo list to "freshen" tiles.  OSM's tile servers
have a feature where you can ask it for the tile's revision.  I'm hoping
to use that in conjuction with dates stored on the tile files to detect
the changes automatically (or when told to check for offline users) and
download only those tiles that indicate changes.

Obviously automatic purging ensures that tiles stay up to date, but
that doesn't help those who want to use the program in an offline mode
with large tile caches.
I'm striving to make it work well in both modes.  I finally got my son,
KJ4DXK, to start using APRSIS32 and he's totally an off-line user.  When
he finishes, APRSIS32 will be an optional viewer and messaging platform
for his home-brew, in-car APRS system (KJ4DXK-9).

Lynn (D) - KJ4ERJ -


James
VE6SRV


------------------------------------

Yahoo! Groups Links

Lynn Deffenbaugh

#550

Would this "alternate" location be the same 256x256 tiles in the same hierarchical naming as the OSM tiles?  If so, that would not be very difficult.  If not, it would be extremely difficult.  And would I only go to this alternate tile set if the OSM fetcher is disabled?  Or under what conditions?

Lynn (D) - KJ4ERJ

m6xsd wrote:

Show quoted text

Hi Again Lynn,

I've been giving the issue of alternative mapping a bit more thought and wondered if you could implement an 'alternative set of tiles' that could be stored in an alternative location and toggled somehow. And if the required tile isn't found in the 'currently preferred' location then the other location is temporarily used (with a suitable indication on the screen.

73,
Colin.

--- In aprsisce@yahoogroups.com, "Lynn W. Deffenbaugh" <kj4erj@...> wrote:
  
James Ewen wrote:
    
On Mon, Mar 1, 2010 at 3:39 PM, Lynn W. Deffenbaugh <kj4erj@...> wrote:

If James sould just put a &#92; at the end of his OSM.Path, he would find
that the file structures are identical.
    That would be cool... I'm just not sure how I get the two to match up...

Here's my path qualifier:

<OSM.Path>C:&#92;Documents and Settings&#92;jame&#92;My Documents&#92;RadioMobile
Data&#92;OSM&#92;OSMTiles&#92;</OSM.Path>

And here's the tile at zoom level 13 that has my house on it.

C:&#92;Documents and Settings&#92;jame&#92;My Documents&#92;RadioMobile Data&#92;OSM13&#92;1518&#92;2648.png
  Edit the XML file (http://aprsisce.wikidot.com/editing-xml-configuration) and remove the OSMTiles&#92; from the end of the list, so that the OSM.Path ednds in ...Data&#92;OSM&#92;

RadioMobile stores the same tile as:

C:&#92;Documents and Settings&#92;jame&#92;My Documents&#92;RadioMobile
Data&#92;OSM&#92;13&#92;1518&#92;2648.png

Note that one pesky slash between the OSM and 13...
  Actually, I thought it was RadioMobile that didn't have the slash.  See if the above change works.

 However, if you point
APRSISCE/32 to the same directory as another program, be aware that
tiles will be fetched and purged as if they were owned by APRSISCE/32.
This may or may not be desired behavior.
    Overriding purging is the answer to that issue... however that brings
up another question. Can you force a fetch of tiles in an area? The
OSM map is constantly in flux as new information is added. With
RadioMobile, I kept a large cache of tiles available. However when new
tiles became available in an area, I would have to manually delete the
tiles in that area. Obviously not an easy thing to do manually, so
wholesale deletion was the simple solution. This of course means that
all of the tiles need to be fetched again. When you are talking about
gigabytes of tiles, that can be a very long task. Being able to keep
the majority of tiles, and only fetching ones  selected by the user
would be a good thing.
  I've got items on the ToDo list to "freshen" tiles.  OSM's tile servers have a feature where you can ask it for the tile's revision.  I'm hoping to use that in conjuction with dates stored on the tile files to detect the changes automatically (or when told to check for offline users) and download only those tiles that indicate changes.

Obviously automatic purging ensures that tiles stay up to date, but
that doesn't help those who want to use the program in an offline mode
with large tile caches.
  I'm striving to make it work well in both modes.  I finally got my son, KJ4DXK, to start using APRSIS32 and he's totally an off-line user.  When he finishes, APRSIS32 will be an optional viewer and messaging platform for his home-brew, in-car APRS system (KJ4DXK-9).

Lynn (D) - KJ4ERJ -

James
VE6SRV

------------------------------------

Yahoo! Groups Links

------------------------------------

Yahoo! Groups Links

Colin Catlin <m6xsd@...>

#551

I think ‘yes’ the same 256x256 tiles/naming makes sense but then I don’t have hundreds of other tiles, perhaps some of the others on here could comment better.

I would suggest that the option to fetch OSM tiles while using the ”alternate tiles” could be useful but perhaps not essential.

I’m thinking of the main use being for walkers / off-roaders (perhaps for SAR) who could use the OSM tiles when using the mainstream roads and then switch to the ”alternate set” when leaving the vehicle (or just before).

Does that make sense?.

73,

Colin.

-----Original Message-----

Show quoted text

From: aprsisce@... [mailto:aprsisce@...] On Behalf Of Lynn W. Deffenbaugh
Sent: 02 March 2010 16:02
To: aprsisce@...
Subject: Re: [aprsisce] Re: Minor details.

Would this "alternate" location be the same 256x256 tiles in the same
hierarchical naming as the OSM tiles? If so, that would not be very
difficult. If not, it would be extremely difficult. And would I only
go to this alternate tile set if the OSM fetcher is disabled? Or under
what conditions?

Lynn (D) - KJ4ERJ

m6xsd wrote:
> Hi Again Lynn,
>
> I've been giving the issue of alternative mapping a bit more thought and wondered if you could implement an 'alternative set of tiles' that could be stored in an alternative location and toggled somehow. And if the required tile isn't found in the 'currently preferred' location then the other location is temporarily used (with a suitable indication on the screen.
>
>
> 73,
> Colin.
>
> --- In aprsisce@yahoogroups.com, "Lynn W. Deffenbaugh" wrote:
>
>> James Ewen wrote:
>>
>>> On Mon, Mar 1, 2010 at 3:39 PM, Lynn W. Deffenbaugh wrote:
>>>
>>>
>>>
>>>> If James sould just put a \ at the end of his OSM.Path, he would find
>>>> that the file structures are identical.
>>>>
>>>>
>>> That would be cool... I'm just not sure how I get the two to match up...
>>>
>>> Here's my path qualifier:
>>>
>>> \Documents and Settings\jame\My Documents\RadioMobile
>>> Data\OSM\OSMTiles\
>>>
>>> And here's the tile at zoom level 13 that has my house on it.
>>>
>>> C:\Documents and Settings\jame\My Documents\RadioMobile Data\OSM13\1518\2648.png
>>>
>>>
>> Edit the XML file
>> (http://aprsisce.wikidot.com/editing-xml-configuration) and remove the
>> OSMTiles\ from the end of the list, so that the OSM.Path ednds in
>> ...Data\OSM\
>>
>>
>>> RadioMobile stores the same tile as:
>>>
>>> C:\Documents and Settings\jame\My Documents\RadioMobile
>>> Data\OSM\13\1518\2648.png
>>>
>>> Note that one pesky slash between the OSM and 13...
>>>
>>>
>> Actually, I thought it was RadioMobile that didn't have the slash. See
>> if the above change works.
>>
>>
>>
>>>> However, if you point
>>>> APRSISCE/32 to the same directory as another program, be aware that
>>>> tiles will be fetched and purged as if they were owned by APRSISCE/32.
>>>> This may or may not be desired behavior.
>>>>
>>>>
>>> Overriding purging is the answer to that issue... however that brings
>>> up another question. Can you force a fetch of tiles in an area? The
>>> OSM map is constantly in flux as new information is added. With
>>> RadioMobile, I kept a large cache of tiles available. However when new
>>> tiles became available in an area, I would have to manually delete the
>>> tiles in that area. Obviously not an easy thing to do manually, so
>>> wholesale deletion was the simple solution. This of course means that
>>> all of the tiles need to be fetched again. When you are talking about
>>> gigabytes of tiles, that can be a very long task. Being able to keep
>>> the majority of tiles, and only fetching ones selected by the user
>>> would be a good thing.
>>>
>>>
>> I've got items on the ToDo list to "freshen" tiles. OSM's tile servers
>> have a feature where you can ask it for the tile's revision. I'm hoping
>> to use that in conjuction with dates stored on the tile files to detect
>> the changes automatically (or when told to check for offline users) and
>> download only those tiles that indicate changes.
>>
>>
>>> Obviously automatic purging ensures that tiles stay up to date, but
>>> that doesn't help those who want to use the program in an offline mode
>>> with large tile caches.
>>>
>>>
>> I'm striving to make it work well in both modes. I finally got my son,
>> KJ4DXK, to start using APRSIS32 and he's totally an off-line user. When
>> he finishes, APRSIS32 will be an optional viewer and messaging platform
>> for his home-brew, in-car APRS system (KJ4DXK-9).
>>
>> Lynn (D) - KJ4ERJ -
>>
>>
>>
>>> James
>>> VE6SRV
>>>
>>>
>>> ------------------------------------
>>>
>>> Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>
>>>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>

Lynn Deffenbaugh

#552

Actually, that described purpose is what the UI-View type .INF maps are for. My plan for those is to allow the user to set a priority on the available non-OSM maps. Whenever one of the non-OSM maps can fully populate the screen at the current zoom level (stretching, shrinking, or cropping as necessary), the highest priority map will be used. I think UI-View does something like this, but I'm not at all sure.

I'm also planning to allow the user to lock into a particular map that will then be used to the exclusion of OSM data until the map selection has been put back on automatic. Of course, you'll also be able to lock onto OSM maps as well.

I was thinking of the "Alternate" tile set as allowing APRSISCE access to, but not purging nor updating of, another supplied OSM-compatible map tile set that may be resident from some other program.

Lynn (D) - KJ4ERJ

Colin Catlin wrote:

Show quoted text

I think yes the same 256x256 tiles/naming makes sense but then I dont have hundreds of other tiles, perhaps some of the others on here could comment better.

I would suggest that the option to fetch OSM tiles while using the alternate tiles could be useful but perhaps not essential.

Im thinking of the main use being for walkers / off-roaders (perhaps for SAR) who could use the OSM tiles when using the mainstream roads and then switch to the alternate set when leaving the vehicle (or just before).

Does that make sense?.

73,

Colin.

-----Original Message-----
*From:* aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com] *On Behalf Of *Lynn W. Deffenbaugh
*Sent:* 02 March 2010 16:02
*To:* aprsisce@yahoogroups.com
*Subject:* Re: [aprsisce] Re: Minor details.

Would this "alternate" location be the same 256x256 tiles in the same
hierarchical naming as the OSM tiles? If so, that would not be very
difficult. If not, it would be extremely difficult. And would I only
go to this alternate tile set if the OSM fetcher is disabled? Or under
what conditions?

Lynn (D) - KJ4ERJ

m6xsd wrote:
Hi Again Lynn,

I've been giving the issue of alternative mapping a bit more thought and wondered if you could implement an 'alternative set of tiles' that could be stored in an alternative location and toggled somehow. And if the required tile isn't found in the 'currently preferred' location then the other location is temporarily used (with a suitable indication on the screen.


73,
Colin.

--- In aprsisce@yahoogroups.com <mailto:aprsisce%40yahoogroups.com>, "Lynn W. Deffenbaugh" <kj4erj@...> wrote:

James Ewen wrote:

On Mon, Mar 1, 2010 at 3:39 PM, Lynn W. Deffenbaugh <kj4erj@...> wrote:



If James sould just put a &#92; at the end of his OSM.Path, he would find
that the file structures are identical.

That would be cool... I'm just not sure how I get the two to match up...

Here's my path qualifier:

<OSM.Path>C:&#92;Documents and Settings&#92;jame&#92;My Documents&#92;RadioMobile
Data&#92;OSM&#92;OSMTiles&#92;</OSM.Path>

And here's the tile at zoom level 13 that has my house on it.

C:&#92;Documents and Settings&#92;jame&#92;My Documents&#92;RadioMobile Data&#92;OSM13&#92;1518&#92;2648.png

Edit the XML file
(http://aprsisce.wikidot.com/editing-xml-configuration <http://aprsisce.wikidot.com/editing-xml-configuration>) and remove the
OSMTiles&#92; from the end of the list, so that the OSM.Path ednds in
...Data&#92;OSM&#92;


RadioMobile stores the same tile as:

C:&#92;Documents and Settings&#92;jame&#92;My Documents&#92;RadioMobile
Data&#92;OSM&#92;13&#92;1518&#92;2648.png

Note that one pesky slash between the OSM and 13...

Actually, I thought it was RadioMobile that didn't have the slash. See
if the above change works.



However, if you point
APRSISCE/32 to the same directory as another program, be aware that
tiles will be fetched and purged as if they were owned by APRSISCE/32.
This may or may not be desired behavior.

Overriding purging is the answer to that issue... however that brings
up another question. Can you force a fetch of tiles in an area? The
OSM map is constantly in flux as new information is added. With
RadioMobile, I kept a large cache of tiles available. However when new
tiles became available in an area, I would have to manually delete the
tiles in that area. Obviously not an easy thing to do manually, so
wholesale deletion was the simple solution. This of course means that
all of the tiles need to be fetched again. When you are talking about
gigabytes of tiles, that can be a very long task. Being able to keep
the majority of tiles, and only fetching ones selected by the user
would be a good thing.

I've got items on the ToDo list to "freshen" tiles. OSM's tile servers
have a feature where you can ask it for the tile's revision. I'm hoping
to use that in conjuction with dates stored on the tile files to detect
the changes automatically (or when told to check for offline users) and
download only those tiles that indicate changes.


Obviously automatic purging ensures that tiles stay up to date, but
that doesn't help those who want to use the program in an offline mode
with large tile caches.

I'm striving to make it work well in both modes. I finally got my son,
KJ4DXK, to start using APRSIS32 and he's totally an off-line user. When
he finishes, APRSIS32 will be an optional viewer and messaging platform
for his home-brew, in-car APRS system (KJ4DXK-9).

Lynn (D) - KJ4ERJ -



James
VE6SRV


------------------------------------

Yahoo! Groups Links








------------------------------------

Yahoo! Groups Links

Colin Catlin <m6xsd@...>

#557

That sounds exactly along the lines I was thinking.
I was thinking the "alternate set" would be the quickest way to start with,
especially for people who have the tiles already.

Show quoted text

-----Original Message-----
From: aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com] On Behalf
Of Lynn W. Deffenbaugh
Sent: 02 March 2010 17:31
To: aprsisce@yahoogroups.com
Subject: Re: [aprsisce] Re: Minor details.

Actually, that described purpose is what the UI-View type .INF maps are
for. My plan for those is to allow the user to set a priority on the
available non-OSM maps. Whenever one of the non-OSM maps can fully
populate the screen at the current zoom level (stretching, shrinking, or
cropping as necessary), the highest priority map will be used. I think
UI-View does something like this, but I'm not at all sure.

I'm also planning to allow the user to lock into a particular map that
will then be used to the exclusion of OSM data until the map selection
has been put back on automatic. Of course, you'll also be able to lock
onto OSM maps as well.

I was thinking of the "Alternate" tile set as allowing APRSISCE access
to, but not purging nor updating of, another supplied OSM-compatible map
tile set that may be resident from some other program.

Lynn (D) - KJ4ERJ

Colin Catlin wrote:

I think 'yes' the same 256x256 tiles/naming makes sense but then I
don't have hundreds of other tiles, perhaps some of the others on here
could comment better.

I would suggest that the option to fetch OSM tiles while using the
"alternate tiles" could be useful but perhaps not essential.

I'm thinking of the main use being for walkers / off-roaders (perhaps
for SAR) who could use the OSM tiles when using the mainstream roads
and then switch to the "alternate set" when leaving the vehicle (or
just before).

Does that make sense?.

73,

Colin.

-----Original Message-----
*From:* aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com] *On
Behalf Of *Lynn W. Deffenbaugh
*Sent:* 02 March 2010 16:02
*To:* aprsisce@yahoogroups.com
*Subject:* Re: [aprsisce] Re: Minor details.

Would this "alternate" location be the same 256x256 tiles in the same
hierarchical naming as the OSM tiles? If so, that would not be very
difficult. If not, it would be extremely difficult. And would I only
go to this alternate tile set if the OSM fetcher is disabled? Or under
what conditions?

Lynn (D) - KJ4ERJ

m6xsd wrote:
Hi Again Lynn,

I've been giving the issue of alternative mapping a bit more thoughtand wondered if you could implement an 'alternative set of tiles' that
could be stored in an alternative location and toggled somehow. And if
the required tile isn't found in the 'currently preferred' location
then the other location is temporarily used (with a suitable
indication on the screen.

73,
Colin.

--- In aprsisce@yahoogroups.com <mailto:aprsisce%40yahoogroups.com>,"Lynn W. Deffenbaugh" <kj4erj@...> wrote:

James Ewen wrote:

On Mon, Mar 1, 2010 at 3:39 PM, Lynn W. Deffenbaugh <kj4erj@...>wrote:

If James sould just put a &#92; at the end of his OSM.Path, he would find
that the file structures are identical.

That would be cool... I'm just not sure how I get the two to matchup...

Here's my path qualifier:

<OSM.Path>C:&#92;Documents and Settings&#92;jame&#92;My Documents&#92;RadioMobile
Data&#92;OSM&#92;OSMTiles&#92;</OSM.Path>

And here's the tile at zoom level 13 that has my house on it.

C:&#92;Documents and Settings&#92;jame&#92;My Documents&#92;RadioMobileData&#92;OSM13&#92;1518&#92;2648.png

Edit the XML file
(http://aprsisce.wikidot.com/editing-xml-configuration<http://aprsisce.wikidot.com/editing-xml-configuration>) and remove the
OSMTiles&#92; from the end of the list, so that the OSM.Path ednds in
...Data&#92;OSM&#92;

RadioMobile stores the same tile as:

C:&#92;Documents and Settings&#92;jame&#92;My Documents&#92;RadioMobile
Data&#92;OSM&#92;13&#92;1518&#92;2648.png

Note that one pesky slash between the OSM and 13...

Actually, I thought it was RadioMobile that didn't have the slash. See
if the above change works.

However, if you point
APRSISCE/32 to the same directory as another program, be aware that
tiles will be fetched and purged as if they were owned byAPRSISCE/32.
This may or may not be desired behavior.

Overriding purging is the answer to that issue... however that brings
up another question. Can you force a fetch of tiles in an area? The
OSM map is constantly in flux as new information is added. With
RadioMobile, I kept a large cache of tiles available. However when new
tiles became available in an area, I would have to manually delete the
tiles in that area. Obviously not an easy thing to do manually, so
wholesale deletion was the simple solution. This of course means that
all of the tiles need to be fetched again. When you are talking about
gigabytes of tiles, that can be a very long task. Being able to keep
the majority of tiles, and only fetching ones selected by the user
would be a good thing.

I've got items on the ToDo list to "freshen" tiles. OSM's tile servers
have a feature where you can ask it for the tile's revision. I'm hoping
to use that in conjuction with dates stored on the tile files to detect
the changes automatically (or when told to check for offline users) and
download only those tiles that indicate changes.

Obviously automatic purging ensures that tiles stay up to date, but
that doesn't help those who want to use the program in an offline mode
with large tile caches.

I'm striving to make it work well in both modes. I finally got my son,
KJ4DXK, to start using APRSIS32 and he's totally an off-line user. When
he finishes, APRSIS32 will be an optional viewer and messaging platform
for his home-brew, in-car APRS system (KJ4DXK-9).

Lynn (D) - KJ4ERJ -

James
VE6SRV

------------------------------------

Yahoo! Groups Links

------------------------------------

Yahoo! Groups Links

------------------------------------

Yahoo! Groups Links

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.733 / Virus Database: 271.1.1/2716 - Release Date: 03/01/10
07:34:00

Fred Hillhouse

#559

I am curious what tiles others have that might be 256x256.

The USGS tiles I have are all 200x200 and they don't play nicely along the edge of an UTM zone.

Now if Lynn was willing to support an alternate tile sizes as well...

Best regards,

Fred

Show quoted text

From: aprsisce@... [mailto:aprsisce@...] On Behalf Of Colin Catlin
Sent: Tuesday, March 02, 2010 13:55
To: aprsisce@...
Subject: RE: [aprsisce] Re: Minor details.

That sounds exactly along the lines I was thinking.
I was thinking the "alternate set" would be the quickest way to start with,
especially for people who have the tiles already.

-----Original Message-----
From: aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com] On Behalf
Of Lynn W. Deffenbaugh
Sent: 02 March 2010 17:31
To: aprsisce@yahoogroups.com
Subject: Re: [aprsisce] Re: Minor details.

Actually, that described purpose is what the UI-View type .INF maps are
for. My plan for those is to allow the user to set a priority on the
available non-OSM maps. Whenever one of the non-OSM maps can fully
populate the screen at the current zoom level (stretching, shrinking, or
cropping as necessary), the highest priority map will be used. I think
UI-View does something like this, but I'm not at all sure.

I'm also planning to allow the user to lock into a particular map that
will then be used to the exclusion of OSM data until the map selection
has been put back on automatic. Of course, you'll also be able to lock
onto OSM maps as well.

I was thinking of the "Alternate" tile set as allowing APRSISCE access
to, but not purging nor updating of, another supplied OSM-compatible map
tile set that may be resident from some other program.

Lynn (D) - KJ4ERJ

Colin Catlin wrote:
>
>
> I think 'yes' the same 256x256 tiles/naming makes sense but then I
> don't have hundreds of other tiles, perhaps some of the others on here
> could comment better.
>
> I would suggest that the option to fetch OSM tiles while using the
> "alternate tiles" could be useful but perhaps not essential.
>
> I'm thinking of the main use being for walkers / off-roaders (perhaps
> for SAR) who could use the OSM tiles when using the mainstream roads
> and then switch to the "alternate set" when leaving the vehicle (or
> just before).
>
> Does that make sense?.
>
> 73,
>
> Colin.
>
> -----Original Message-----
> *From:* aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com] *On
> Behalf Of *Lynn W. Deffenbaugh
> *Sent:* 02 March 2010 16:02
> *To:* aprsisce@yahoogroups.com
> *Subject:* Re: [aprsisce] Re: Minor details.
>
> Would this "alternate" location be the same 256x256 tiles in the same
> hierarchical naming as the OSM tiles? If so, that would not be very
> difficult. If not, it would be extremely difficult. And would I only
> go to this alternate tile set if the OSM fetcher is disabled? Or under
> what conditions?
>
> Lynn (D) - KJ4ERJ
>
> m6xsd wrote:
> > Hi Again Lynn,
> >
> > I've been giving the issue of alternative mapping a bit more thought
> and wondered if you could implement an 'alternative set of tiles' that
> could be stored in an alternative location and toggled somehow. And if
> the required tile isn't found in the 'currently preferred' location
> then the other location is temporarily used (with a suitable
> indication on the screen.
> >
> >
> > 73,
> > Colin.
> >
> > --- In aprsisce@yahoogroups.com 40yahoogroups.com>,
> "Lynn W. Deffenbaugh" wrote:
> >
> >> James Ewen wrote:
> >>
> >>> On Mon, Mar 1, 2010 at 3:39 PM, Lynn W. Deffenbaugh
wrote:
> >>>
> >>>
> >>>
> >>>> If James sould just put a \ at the end of his OSM.Path, he would find
> >>>> that the file structures are identical.
> >>>>
> >>>>
> >>> That would be cool... I'm just not sure how I get the two to match
> up...
> >>>
> >>> Here's my path qualifier:
> >>>
> >>> C:\Documents and Settings\jame\My Documents\RadioMobile
> >>> Data\OSM\OSMTiles\
> >>>
> >>> And here's the tile at zoom level 13 that has my house on it.
> >>>
> >>> C:\Documents and Settings\jame\My Documents\RadioMobile
> Data\OSM13\1518\2648.png
> >>>
> >>>
> >> Edit the XML file
> >> (http://aprsisce.wikidot.com/editing-xml-configuration
> <http://aprsisce.wikidot.com/editing-xml-configuration>) and remove the
> >> OSMTiles\ from the end of the list, so that the OSM.Path ednds in
> >> ...Data\OSM\
> >>
> >>
> >>> RadioMobile stores the same tile as:
> >>>
> >>> C:\Documents and Settings\jame\My Documents\RadioMobile
> >>> Data\OSM\13\1518\2648.png
> >>>
> >>> Note that one pesky slash between the OSM and 13...
> >>>
> >>>
> >> Actually, I thought it was RadioMobile that didn't have the slash. See
> >> if the above change works.
> >>
> >>
> >>
> >>>> However, if you point
> >>>> APRSISCE/32 to the same directory as another program, be aware that
> >>>> tiles will be fetched and purged as if they were owned by
APRSISCE/32.
> >>>> This may or may not be desired behavior.
> >>>>
> >>>>
> >>> Overriding purging is the answer to that issue... however that brings
> >>> up another question. Can you force a fetch of tiles in an area? The
> >>> OSM map is constantly in flux as new information is added. With
> >>> RadioMobile, I kept a large cache of tiles available. However when new
> >>> tiles became available in an area, I would have to manually delete the
> >>> tiles in that area. Obviously not an easy thing to do manually, so
> >>> wholesale deletion was the simple solution. This of course means that
> >>> all of the tiles need to be fetched again. When you are talking about
> >>> gigabytes of tiles, that can be a very long task. Being able to keep
> >>> the majority of tiles, and only fetching ones selected by the user
> >>> would be a good thing.
> >>>
> >>>
> >> I've got items on the ToDo list to "freshen" tiles. OSM's tile servers
> >> have a feature where you can ask it for the tile's revision. I'm hoping
> >> to use that in conjuction with dates stored on the tile files to detect
> >> the changes automatically (or when told to check for offline users) and
> >> download only those tiles that indicate changes.
> >>
> >>
> >>> Obviously automatic purging ensures that tiles stay up to date, but
> >>> that doesn't help those who want to use the program in an offline mode
> >>> with large tile caches.
> >>>
> >>>
> >> I'm striving to make it work well in both modes. I finally got my son,
> >> KJ4DXK, to start using APRSIS32 and he's totally an off-line user. When
> >> he finishes, APRSIS32 will be an optional viewer and messaging platform
> >> for his home-brew, in-car APRS system (KJ4DXK-9).
> >>
> >> Lynn (D) - KJ4ERJ -
> >>
> >>
> >>
> >>> James
> >>> VE6SRV
> >>>
> >>>
> >>> ------------------------------------
> >>>
> >>> Yahoo! Groups Links
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
>
>
>
>

------------------------------------

Yahoo! Groups Links

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.733 / Virus Database: 271.1.1/2716 - Release Date: 03/01/10
07:34:00