|
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
|
|
|
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
|
|
|
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
|
|
|
--- 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)? :)
|
|
|
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:\APRSISCE\OSMTiles\</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.aspDan 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
|
|
|
--- 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
|
|
|
|
Is your call sign NSEXY?
;)
toggle quoted messageShow quoted text
--- 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
|
|
|
|
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
|
--- 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?
;)
--- 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
|
|
|
|
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:\APRSISCE\OSMTiles\</OSM.Path>
Maybe James can edit this line to support RadioMobile and APRSISCE?
If James sould just put a \ 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
|
|
|
--- 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:\APRSISCE\OSMTiles\</OSM.Path>
Maybe James can edit this line to support RadioMobile and APRSISCE?
If James sould just put a \ 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
|
|
|
--- 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!
|
|
|
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:\APRSISCE\OSMTiles\</OSM.Path>
Maybe James can edit this line to support RadioMobile and APRSISCE?
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: <OSM.Path>C:\Documents and Settings\jame\My Documents\RadioMobile Data\OSM\OSMTiles\</OSM.Path> 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 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... 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
|
|
|
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:
<OSM.Path>C:\Documents and Settings\jame\My Documents\RadioMobile
Data\OSM\OSMTiles\</OSM.Path>
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
|
|
|
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-----
toggle quoted messageShow 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
>
>
>
>
>
|
|
|
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.
toggle quoted messageShow 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 \ 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:\Documents and Settings\jame\My Documents\RadioMobile
Data\OSM\OSMTiles\</OSM.Path>
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
|
|
|
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:
toggle quoted messageShow 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 \ 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:\Documents and Settings\jame\My Documents\RadioMobile
Data\OSM\OSMTiles\</OSM.Path>
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
|
|
|
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-----
toggle quoted messageShow 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
>
>
>
>
>
|
|
|
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:
toggle quoted messageShow 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 \ 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:\Documents and Settings\jame\My Documents\RadioMobile
Data\OSM\OSMTiles\</OSM.Path>
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
|
|
|
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.
toggle quoted messageShow 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 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 \ 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:\Documents and Settings\jame\My Documents\RadioMobile
Data\OSM\OSMTiles\</OSM.Path>
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
|
|
|
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
toggle quoted messageShow quoted text
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
|
|
|
