PLT file format

KarlBouchard

Hi all,

where can I find the specifications for PLT files? I want to write a C++ application that will read a PLT file.

Thanks

Karl

IanMacLeod

Karl,

That is a very old format indeed, developed over 30 years ago as a container for what we then called "high-level graphics". A quick scan of my library could not find a reference, but I know others have created PLT interfaces so the reference must have existed at one time. Perhaps someone still has a document?

The current API is able to read a PLT file into a map, and it uses what we call the "pp class" to pull this off. If you are prepared to spelunk come code, I placed the Geosoft "C" class that deals with this in my github account (https://github.com/ianneilmacleod/IanMacLeod/tree/master/GeosoftSource/geoengine.map/pp). pppmf.c iterates the content of a PLT file and reduces this to primitives that are written through a DD driver. I placed the MVIEW DD driver code here: https://github.com/ianneilmacleod/IanMacLeod/tree/master/GeosoftSource/geoengine.map/mdd

Sorry, but I cannot help much beyond this.

Good luck, Ian

KarlBouchard

Hi Ian,

sorry for the late response, I was out on vacation. Thanks for the code, it was quite interesting to browse through.

Even if the PLT format is old, it is still useful. It allows me to find the exact position/characteristics of elements on a map. If this was available through the GX api, I wouldn't be messing with PLT files but right now it's my best option.

I was able to find a copy of my own very old PASCAL programs that read and wrote PLT files and also a copy of the 1995 GEOSOFT MPS Technical Reference Appendix Manual which details the PLT format and many others. With this I wrote a new C++ PLT file reader.

Reading your code, I see that there are more "new" PMF for views (type 50 and 51) and groups (type 52 and 53), which is really cool. Unfortunately they don't show up in my PLT files. I use GXMAP::export_all_in_view to create the PLT file but it doesn't seem to create those PMF. Can you confirm if they are supposed to be used by the export function? May be I'm not using it correctly.

Also, there is a new PMF (type 42) for which I couldn't find any reference in your code. From what I can see it's related to grids. It's not really important for me right now but it would be nice to have the complete PMF definitions.

Is there 2017 Technical Reference Manual that explains the different file formats? Not just PLT files but also MAP, GRD etc? I'm reading PLT files but I could just as well use MAP files directly.

Thanks for all of your help

Best regards

Karl

IanMacLeod

Karl,
Sorry, but we are crossing vacations... I am away till next week (typing from an airport right now), but I'll try to give you a better response tomorrow.
Ian

IanMacLeod

Karl,

It was about 1995 that we moved from PLT files as the primary storage for graphics to the current Geosoft .MAP files. This was, and is, a more "object-orented" design built on the Geosoft class pattern, which at the time we implemented in C. All Geosoft storage moved to this design, which most notably provided a future-proof versioning capability. The design allowed us to modify the format and add new class serializations as they came along, and we have indeed done this as we moved to 3D and many other more complex structures. The versioning capabilities meant that old versions of Geosoft could open new .MAP files, and vice versa, and this has been a very important capability that Geosoft users value, though admittedly we all take for granted because it works so well. It is remarkable that we have achieved version stability over almost 25 years while at the same time adding significant new features.

One consequence of this shift was that we only expose the content of such class-oriented files via the API as that is the only way you can benefit from the version-safe aspect. Also, the physical file format is actually quite complex and nuanced, and this complexity is buried in the class structures, as it should be. We are just not in a position to support this complexity, unfortunately, and we have left it hidden within the system.

As we move forward with the API, we continue to be committed to expanding and improving the empowerment of developers. I expect we will be adding a map file iterator at some point as this would better support applications like your own, and I do wish I had one for my own Python work. I cannot say when that will become available as it comes down to priorities.

I appreciate this is not much help, but I hope it helps you understand the context of how Geosoft storage has evolved, and the commitment we have to continue to expand and support current and future Geosoft storage via the GX API.

Ian

KarlBouchard

Hi Ian,

thanks for your response.

My main concern was that I'm working with a 20 year old obsolete file format about which no one seems to have a lot of knowledge. That got me thinking that maybe working with the current file format would be a better idea! If it's not possible to do so, I'll stick to the PLT format but you have to promise to keep supporting it until that map iterator comes out...

Any update on GXMAP::export_all_in_view? Can it create the view and group PMFs when exporting? If I'm stuck with using the PLT files, at least I'd like to squeeze the most out of them.

Once again, I greatly appreciate your help.

Best regards,

Karl

IanMacLeod

Karl,

I just tested GXMAP::export_all_in_view, and unfortunately it creates a raw PLT file in the units of the specified view without the view and group names. I tested this by importing the PLT file into a new map, and all view and group names are lost. It is possible that the PLT importer skips these names, so if it is important to you I suggest you test with your own reader to see if these names are indeed embedded in the PLT file.

Ian

KarlBouchard

Hi Ian,

the view and group names are not in embedded in the PLT files. So would this be considered a bug or a feature?

I'm looking to get the coordinates of a specific plot element on within a view/group. Since I don't have the view/groups in the PLT file, I use the group extent to restrict my search. This is not the best because different groups overlap. If the view/group were present, I could search only the elements that are truly within the group.

Anyway, by using the PLT file and group extent I'm able to achieve my goal. It's not the optimal way or the most future-proof way but it works. I guess that's the most important thing now. Don't kill PLT file support before you get that map file iterator ready!

Thanks for your help

Best regards,

Karl

IanMacLeod

Karl,

Thanks for testing this. I would not consider this a bug, or a feature for that matter, just a characteristic of the "export_all_in_view" function.

You can feel confident we will not remove PLT file support, though it is unlikely we will improve PLT support as time would be better spent on things other things, such as a map/view/group iterator .

Best, Ian

IanMacLeod

Karl,
Have you tried:

GXMVIEW::mark_all_groups() to un-mark all groups
GXMVIEW::mark_group() to mark the group you want
GXMAP::export_all_in_view()

This should just export the group you want.

KarlBouchard

Hi Ian,

thanks for the suggestion. I tried it and unfortunately the plt file still contains the data from all groups.

Did you get this to work on your data or was it just an idea to try?

Regards,

Karl

IanMacLeod

Karl,

No, I had not tried it, and you are right, it does not work as I expected. Marking is different from hiding, but the mark can be used to choose what to hide, so the following does work, which I just tested.

Say you want to export and delete the group named "North" from the the "Base" view.

Open the "Base" view:

GXMVIEW::mark_all_groups(1) # marks everything
GXMVIEW::mark_group('North', 0) # unmarks 'North'
GCMVIEW::hide_marked_groups(1) # now only the 'North' group is visible
GXMAP::export_all_in_view()
GXMVIEW::delete_group('North') # delete this group, assumes you want to replace it.

BTW, I'm testing from Python, but it uses the same underlying API so this should work from any language.

KarlBouchard

Hi Ian,

thanks for the info. It worked great. I went from 20 files being created down to a single very small PLT file. That's just what I needed.

Thanks again for your help, I really appreciate it

Best regards,

Karl