Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Mon 24 Nov 2014, 18:59
All times are UTC - 4
 Forum index » Advanced Topics » Additional Software (PETs, n' stuff) » Engineering/Science/Simulation
Place-n-Time map viewer
Post new topic   Reply to topic View previous topic :: View next topic
Page 2 of 2 [27 Posts]   Goto page: Previous 1, 2
Author Message
npierce

Joined: 28 Dec 2009
Posts: 858

PostPosted: Fri 30 Aug 2013, 16:30    Post subject:  

Hi Karl,

Assuming that you are still getting "Error allocating memory for <nad_file_list>", I have an idea.

Although I am still puzzled by that error (since your lookup_nad file seems to be good), I have a work-around that might get Place-n-Time to run for you. If that works, we can get back to this error later.

The work-around is to rename lookup_nad so that the application can't find it. It should then give you this message when started from a terminal, and keep running:
Code:
Couldn't open lookup file: /usr/local/share/placentime/essential/lookup_nad.

(or something similar if you have modified placentimerc.first).

The reason that this might work for you (and does for me) is that the "nad_file_list" is currently only used to transform the coordinates in GNIS files that use a different horizontal datum than that used by the DLG files. But the sample GNIS files included in the package use the same datum as the DLG files. (The same is true of all the GNIS files available here: GNIS)

In theory, and in this version of Place-n-Time, hiding that file might only be a problem if you got a GNIS file form a different source. I could be wrong.

Anyway, it would be worth trying.


Karl Godt wrote:
It might be caused by recompiled libraries on my side too .

Yes, possibly. If so we may run into further problems even with the above work-around. We'll see.


Karl Godt wrote:
I hope that lack of a current available reasonable speed or lack of any internet connection nor firewall issues do not choke some features of the program .

That shouldn't be a problem. When simply looking at the USGS DLG files it never goes to the Internet for anything. It just uses the sample files and any files that you have manually downloaded.
Back to top
View user's profile Send private message 
Karl Godt


Joined: 20 Jun 2010
Posts: 3972
Location: Kiel,Germany

PostPosted: Fri 30 Aug 2013, 17:15    Post subject:  

Quote:
Understood, US only. However, since Karl is in Europe and you were pleased he had tried “it” I just followed his example, because you have both cracked problems for me.


Yeah , am setting up my main Puppy full installation now on four partitions with busybox ash preferring its applets before calling external binaries , with a mainly pristine /root directory from the orginal .sfs to start half new without that tons of personal crap that filled /root in use for two or three years now and experiment further .

That Puppy is Macpup Foxy 3 that is a mix of Puppy-430 and ttuuxxx's Puppy-432 with an unusual libgtk v1.16.x compiled by ttuuxxx that lacks svg support .

Actually | was missing a googlemaps package like googleearth .
I am also a bit interested in geographic maps , so am keen on playing around with it .

So expect loads on frugals and observations next first and second of September !
Back to top
View user's profile Send private message Visit poster's website 
Karl Godt


Joined: 20 Jun 2010
Posts: 3972
Location: Kiel,Germany

PostPosted: Fri 30 Aug 2013, 18:15    Post subject:  

OK Norman :

I renamed that file to *-out and the whole thing at least now opened a white window but without any content but searching at the bottom . Also the memory and cpu usage wasn't that much any more .

I ran it with the renamed file
1: strace placentime_view 2>placentime_view.ste

and renamed the file to its original name again
2 : strace placentime_view 2>placentime_view.02.ste

Attached :
Both strace text files real .tar.bz2 and screenshots
Pics are 1920x1080 reduced to 15color .gif to reduce size to be able to upload , hopefully showing a little since the mtpaitsnapshot took several seconds second time to find cpu to be processed :

[ Hmmm ... strace files showed a lot of locale hints .. so lookup_nad might need to use comma instead of colon in my locale :

bash-3.00# locale
LANG=C
LC_CTYPE=de_DE.utf8
LC_NUMERIC=de_DE.utf8
LC_TIME=de_DE.utf8
LC_COLLATE=en_US
LC_MONETARY=de_DE.utf8
LC_MESSAGES=de_DE.utf8
LC_PAPER=de_DE.utf8
LC_NAME=de_DE.utf8
LC_ADDRESS=de_DE.utf8
LC_TELEPHONE=de_DE.utf8
LC_MEASUREMENT=de_DE.utf8
LC_IDENTIFICATION=de_DE.utf8
LC_ALL=

]
placentime_debug-krg-2013-08-29.tar.bz2
Description  both strace text files
bz2

 Download 
Filename  placentime_debug-krg-2013-08-29.tar.bz2 
Filesize  65.56 KB 
Downloaded  218 Time(s) 
placentime_view-wo-lookup_nad.gif
Description  without lookup_nad
gif

 Download 
Filename  placentime_view-wo-lookup_nad.gif 
Filesize  132.51 KB 
Downloaded  234 Time(s) 
placentime_view-normal.gif
Description  with lookup_nad
gif

 Download 
Filename  placentime_view-normal.gif 
Filesize  170.19 KB 
Downloaded  238 Time(s) 
Back to top
View user's profile Send private message Visit poster's website 
npierce

Joined: 28 Dec 2009
Posts: 858

PostPosted: Fri 30 Aug 2013, 22:35    Post subject:  

Karl,

This is excellent feedback that you have provided. Very Happy

The strace logs and the screenshots were very helpful.

As you may have noticed, the strace log made when lookup_nad was available shows that placentime_view reads only the first line of that file, then endlessly starts allocating more memory. It never even advances to the second line of the file. The first line was enough to confuse it.

Similarly, the strace log made when lookup_nad was hidden shows that placentime_view reads the first line of /usr/local/share/usgs/dlg24/lookup, then it gets stuck. (That file is used by placentime_view to look up the name of the file containing the map data for a given latitude and longitude.)

It both cases it is reading floating-point numbers, so the problem, just as you suggested it might be, is related to the locale. The files use a . for a decimal point, but since the locale was de_DE.utf8 it was expecting a , to be used.

You are good!

Once I changed my locale to de_DE.utf8, I started to get the symptoms that you did.

So I'll have to teach placentime_view that it should expect a . for a decimal point in these files, no matter what the locale happens to be. In the meantime, the work-around is of course:
Code:
LANG=C placentime_view

or even:
Code:
LC_NUMERIC=C placentime_view


Bugs like this are just the type that I am hoping to uncover -- stuff I never thought to test for myself.

Many thanks.
Back to top
View user's profile Send private message 
Karl Godt


Joined: 20 Jun 2010
Posts: 3972
Location: Kiel,Germany

PostPosted: Fri 30 Aug 2013, 23:17    Post subject: works with LC_NUMERIC=C  

Code:
bash-3.00# export LC_NUMERIC=C
bash-3.00# locale
LANG=C
LC_CTYPE=de_DE.utf8
LC_NUMERIC=C
LC_TIME=de_DE.utf8
LC_COLLATE=en_US
LC_MONETARY=de_DE.utf8
LC_MESSAGES=de_DE.utf8
LC_PAPER=de_DE.utf8
LC_NAME=de_DE.utf8
LC_ADDRESS=de_DE.utf8
LC_TELEPHONE=de_DE.utf8
LC_MEASUREMENT=de_DE.utf8
LC_IDENTIFICATION=de_DE.utf8
LC_ALL=
bash-3.00# placentime_view

placentime, rev 0.03, 2012-May-19
Copyright 2012 Dapper Mapper
All Rights Reserved


Very Happy Idea
placentime_LC_NUMERIC_C.gif
 Description   
 Filesize   32.12 KB
 Viewed   229 Time(s)

placentime_LC_NUMERIC_C.gif

Back to top
View user's profile Send private message Visit poster's website 
amigo

Joined: 02 Apr 2007
Posts: 2277

PostPosted: Sat 31 Aug 2013, 03:20    Post subject:  

I'll ask again, are the sources available?
Back to top
View user's profile Send private message 
Jasper


Joined: 25 Apr 2010
Posts: 1159
Location: England

PostPosted: Sat 31 Aug 2013, 04:44    Post subject:  

amigo,

No, not yet.
-----------------
was your answer.
Back to top
View user's profile Send private message 
npierce

Joined: 28 Dec 2009
Posts: 858

PostPosted: Sat 31 Aug 2013, 15:53    Post subject:  

Karl, you got it! Very Happy

That is good to see. Very Happy Very Happy
Back to top
View user's profile Send private message 
Karl Godt


Joined: 20 Jun 2010
Posts: 3972
Location: Kiel,Germany

PostPosted: Sat 31 Aug 2013, 16:09    Post subject:  

But very basic interface !

No scrollbars , apparently no text markers on the maps for easy orientation , using a better near view scale made 75% of the map unreachable .

Still lot of work to do ?
Back to top
View user's profile Send private message Visit poster's website 
npierce

Joined: 28 Dec 2009
Posts: 858

PostPosted: Sat 31 Aug 2013, 17:40    Post subject:  

Karl Godt wrote:
. . . apparently no text markers on the maps for easy orientation . . .

Yes, that is true.

The primary reason for that is that the map data files contain no name information other than the state, county, and sometimes the town (and even then they just have numbers that placentime_view looks up in another database). That's the information that you see in the lower right-hand corner. But I agree that having the text appear right on the map would make for easier orientation, since that could show multiple names and not require the user to point with the mouse to identify a town.

Highway route numbers are also available, and I hope to add those to the map. Currently they are only available by pointing at a road and using the context menu to choose What's This?.

As for other things like lakes, mountains, parks, and such, the map data files contain no names. I have tried to fill that hole with the GNIS (Geographic Names Information System) files. These are a separate data set, having no connection with the map data files. Based on the latitude and longitude of the point, choosing What's This? from the context menu will also provide the name of an object if the Show GNIS toggle button is set in the What's This? dialog. But again, I hope to eventually display them right on the map, selectively, depending upon the zoom level.

The original scope of this project was simply to create an application to specifically view these USGS "digital line graphs" (DLGs), not to create a general-purpose atlas type application which had been done many times before. Since there was very little name data in the DLG files, names were not originally a high priority.

However, now I would like the application to be useful to a wider audience, so certainly names will be a higher priority going forward.

Karl Godt wrote:
. . . using a better near view scale made 75% of the map unreachable.

You should be able to drag the map around with the middle mouse button.

Karl Godt wrote:
No scrollbars . . .

No. Scrollbars have limits. The surface of the earth does not. Smile

Karl Godt wrote:
Still lot of work to do ?

Always!

The list of the things I want to do seems almost as limitless as the surface of the earth. "What to do next?" is always a tough question. But getting good feedback from others helps me to decide where my priorities should lie.

Thanks for the good feedback.
Back to top
View user's profile Send private message 
Karl Godt


Joined: 20 Jun 2010
Posts: 3972
Location: Kiel,Germany

PostPosted: Sat 31 Aug 2013, 19:44    Post subject:  

Quote:
You should be able to drag the map around with the middle mouse button.

Of course, all my mice have some awkward flaws, and this one has the button 3 not working but button 6 (forward thumb button) Very Happy

Here a better shot, but would switch to google maps for now , probably because neighbor cards show too .
Dunno, are the forest boundaries black or dark green ?
VT.jpg
 Description   
 Filesize   67.13 KB
 Viewed   203 Time(s)

VT.jpg

Back to top
View user's profile Send private message Visit poster's website 
npierce

Joined: 28 Dec 2009
Posts: 858

PostPosted: Sat 31 Aug 2013, 23:08    Post subject:  

Karl Godt wrote:
Dunno, are the forest boundaries black or dark green ?

In the intermediate scale data files, and I think in the large scale data files as well, state forest polygons are given an entity code that identifies them as a state forest or grassland. Place-n-Time displays the entire polygon in dark green.

In the small scale data files (as used for the map in your screen shot) state forest polygons have no entity code. Place-n-Time doesn't color those polygons, and their boundaries show as thin black lines.

By the way (as you may have already discovered), if you point to the white area just to the east of the state of Vermont map, you can use the context menu to load a small scale map of the state of New Hampshire adjacent to the Vermont map. You could do the same for the states to the west and south except that I didn't include them in the sample files. (Perhaps I should have included more sample maps, but I thought that the package was already a bit hefty, since it takes about 40 MiB when installed.)
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 2 of 2 [27 Posts]   Goto page: Previous 1, 2
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Additional Software (PETs, n' stuff) » Engineering/Science/Simulation
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0920s ][ Queries: 13 (0.0048s) ][ GZIP on ]