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:

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.

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 !

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 :

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.

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.

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.

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.)

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