ThinkGeo.com    |     Documentation    |     Premium Support

Write Overlay to Sqlite

#1

Hi,

I’m trying to get rid of GeoSerializer so I can start migrating from v10 to the latest. I’m already using sqlite, so I figured I would just write my overlays to the database and then read them back on opening the program.

It works as follows:

  1. Gather all layers and parameters I want to save to an object (same object I use today with GeoSerializer)
  2. Convert the object to a byte[]
  3. Write the byte[] to the db
  4. Read the byte[] from the db
  5. Cast the byte[] back to object and load layers to map

The objects all look good at step 5, but when I try and add the layers to the map I get the following error on refreshing the map.

Object reference not set to an instance of an object.

After inspecting the overlay and comparing back to the same overlay returned from GeoSerializer I notice several internal parameters that are null in the sqlite record but are not null in the GeoSerializer record. Here are the ones.

image

What can I do to make this work?

Regards,
Damian

#2

Hi Damian,

I wanted to verify a couple of points:

  1. In #1, does the object include ThinkGeo v10 layers, and in #2, were you using the GeoSerializer in v10 to serialize that object to a byte[]?
  2. In #5, were you using the GeoSerializer in v14 to deserialize from the byte[] into v14 layers, and then adding those layers to the v14 map?

If the answers to both questions are “yes,” I’m afraid there is no direct way to serialize a v10 layer to a byte[] and then deserialize it into a v14 layer, because the layer structures in the two versions are inconsistent. Practically speaking, you can’t transition directly between these versions using GeoSerializer.

Alternatively, you can write code to extract (or “cherry-pick”) the key properties you want to preserve (in primitive data formats), serialize those properties to a byte[], and then initialize the v14 layers using that data.

Thanks,
Ben

#3

Hi Ben,

In #1 I was not using GeoSerializer. I was just formatting my layers directly to byte[].

In #5 I was just trying to get it back into the v10 map.

I am experimenting now with json serialization based on another query I had with you some time ago. The json format does not specify any specific namespaces unlike GeoSerializer, so I was hopeful I could go from v10 to v14 using json. I do not want to try and script all the namespace changes and rewrite user save files. I did that once before and it was a real pain.

So far I see a few errors with json, but not sure why. Here’s one.

image

You say cherry-pick properties, but how am I to know which ones are important for rebuilding different layers? This IsEditable for example could be skipped over I assume, but do I just keep doing this through trial and error???

My end goal here is to get a save format that can handle changes you guys make so it’s easier for us to integrate your updates. Recommendations would be helpful and appreciated.

Regards,
Damian

#4

Hi Damian,

I assume you’re using JSON to serialize all the fields. However, some default fields may fail to deserialize because they’re handled differently during initialization. Even if you exclude those problematic fields and successfully rebuild v10 objects through JSON serialization, it won’t reliably create compatible objects in v14.

I recommend collecting only the essential property values that your application sets in v10, and then using those properties to recreate the objects in v14. Unfortunately, there isn’t a straightforward way to migrate via serialization alone—there are simply too many breaking changes between v10 and v14 for that to work seamlessly.

Thanks,
Ben