Question of the Week: Reading and Writing Nested Zipped Shapefiles

Hello FME'ers

In the week that we hosted a webinar all about the Shapefile format, it's appropriate to have a question-of-the-week on the same subject.

Question of the Week

This week's question came from a user on Live Chat and concerns how to read Shapefiles nested inside multiple folders inside a compressed Zip file.

Q) I have a URL for a “zipped” shapefile. However, the shapefile is actually nested two folders into the zip file.

 

If I download this file from the browser and set the Shapefile reader dataset to: 

/Users/[username]/Downloads/MajorRoads.zip/**/**/*.shp

 

...then this is read in properly by FME. However when applying a similar logic to a URL: 

http://[server]/data/downloads/roads.zip/**/**/*.shp

 

...then FME fails to read the shapefile. The download begins but errors when trying to create feature types.

Is this the expected behaviour?

A) There are two forms of what we might call "path filtering." 

The older style - which you are trying to use - is now obsolete, and won't work with URLs because we can't tell where the URL ends and the path begins.

However, there is a newer style of path filtering that will resolve the issue. Let's see how - and also look at an update for writing nested zipped Shapefiles in 2020.

 

Placed in the Same Bracket

The new syntax for handling nested zip files relies on using square brackets, namely [ and ].

In the FME documentation, the usage notes for Reading Archive Files explains how this works:

Basically, you put square brackets around the part that represents folders inside the zip file. In the above example, the path you set to read directly from the URL should look like this:

http://[server]/data/downloads/roads.zip[**/**/*.shp]

Now it will work fine.

It's Full of Stars!

Oh, you may have noticed that having two sets of 

**

 characters is actually redundant. That's because 

**

 means recurse down the whole depth of the path until you find a file. So you would only ever need one of these.

So the path above should really be:

http://[server]/data/downloads/roads.zip[**/*.shp]

Unless you wanted to go exactly two levels deep, in which case the URL would look like this:

http://[server]/data/downloads/roads.zip[*/*/*.shp]

It's a minor issue, but worth getting right.

Writing Nested Zipped Shapefiles

On a similar topic, a recent update improves the capability to write nested zipped datasets. This scenario isn't where there is a series of nested folders in the output zip file, but where we want a series of nested zip files, inside one another.

For example, say you wanted to write the following output:

c:\[folder]\Output.zip\Shapefiles.zip\PrimaryRoads.zip

...where there is a zip file of output, that contains a zip file of Shapefiles, that contains a zip file of roads!

Another use for this is in FME Server Data Downloads. The Data Download service creates its own zip files when it writes the output datasets. But if you specify the output dataset was also to be a zip file, then that would be nested zips.

Up until recently, this would not work (as discovered by users here and here) because the zipped output dataset could not be nested.

I actually tweeted that this could be done:

...but I think I was wrong. This couldn't be done. What I was getting was a zipped file inside a plain folder that just happened to have .zip in its name (hey, it's an easy mistake to make).

However, in FME2020 I can do things like this:

...and create one zipped file inside another. I can even create fanouts like:

c:\[folder]\Output.zip\Parks.zip\[NeighborhoodName].zip

Plus you can now deploy writing zipped datasets to a Data Download service on FME Server!

Thanks to @andreaatsafe, Graeme, and Harbinder (the latter two are developers at Safe) for providing this information.

Other Notable Questions

Here are some other interesting questions:

• From Live Chat: I'm writing data to a Spatialite DB from MicroStation files and am getting a warning "Unsupported geometry type Path. Downconverting to a line."
  • Paths are a variation of a line type geometry, made up multiple segments such as lines and arcs. FME will preserve the path from MicroStation but the Spatialite DB writer will complain about it. Use the PathSplitter transformer to purposely split up path features.
• From Live Chat: We require Esri’s ArcGis with 64-bit background processing. Is this supported in the Kubernetes version of FME Server?
  • As Kubernetes and Docker are built on Linux containers, it's not possible to use these formats. This page on our web site shows what formats are supported for Linux (choose 'Compare by Platforms').
• @nicholas asks: How can I tell the most common network ID from the NetworkTopologyCalculator?
  • As @drc43 notes, the StatisticsCalculator is the transformer of choice. I was thinking you'd group by the network ID and then use the count value for each, then a Sorter to sort the data and a Sampler to pick the first record, but - as was pointed out - the Mode result is exactly what you are looking for! As simple as that!
• Bin Packing Problem!
  • @tk_st asks how we might do bin packing in FME. I'm not sure, but I've skirted the edge of this problem before and find it fascinating. I'll put my thinking cap on, but anyone else, please do have a look and see what you think!
• Exposing Attributes Dynamically
  • What @eduardojsilvajr really needs is a way to convert rows into columns. The AttributePivoter (Group Row By City, Group Columns By Date) should do the task, but seems to have a bug that causes a crash. This looks like it's for Covid research, so if anyone has any other bright ideas, please do share.