Cannot import json with vector data.

Dimitri

7,592 post(s)

#04-Oct-25 07:01

The first step when trying to import something is to read the user manual topic(s) on importing/linking that format.

If something unexpected happens on import, there are three key questions to answer why something that claims to be a standard format does not import as you expect when you use dataports that are designed to import standard formats.

1. What software was used to create that file?

2. What format is it claimed to be?

3. What does the file actually contain?

Saying a file is a "json" file means nothing when it comes to importing geospatial data, because JSON is just a notation style for writing about data. It can be whatever you want it to be. The following is a JSON file:

{

"todaysdate":"I think it's a Saturday",

"todaysyear": {

"exact":"Not sure, but maybe it's in the Age of Aquarius"

"fields": "I like wheat fields, before they are cut and get filled with yucky stubble",

"features": "There's a pink blob in the drawing but when I move the mouse it disappears"

}

...it's also complete nonsense. That somebody uses JSON notation doesn't mean the text that is contained in a file with a .json extension has to make any sense or use any generally agreed upon standard.

That's why the GeoJSON topic comments...

The GeoJSON and JSON dataports are different, since GeoJSON is a well-specified standard, while a generic JSON file need not follow any standard for data organization. As a practical matter, JSON files are thus useful for interchanging tables in relatively calm use of JSON, such as arrays.

and why the JSON topic comments...

JSON files vary wildly - In the above example we imported a JSON file that used JSON in a relatively simple way, to store a table. If the file had only three records, we could open it in Notepad (JSON files are plain text files) and see:
[{"id":1,"first_name":"Hermina","last_name":"Stanworth","email":"hstanworth0@dailymotion.com","gender":"Female"},
{"id":2,"first_name":"Ellyn","last_name":"Wildash","email":"ewildash1@yellowbook.com","gender":"Female"},
{"id":3,"first_name":"Karna","last_name":"Collison","email":"kcollison2@accuweather.com","gender":"Female"}]
JSON files can, and sometimes do, structure data using arrangements that make little sense except to software written by the original authors. In such cases, Manifold will use all sensible means to extract data that looks like it should be a table from the JSON file, and toss all other top level objects into comments components.

If we ask question number 3 above and take a look at your .json file with Notepad, we learn immediately it is not one of the two standards that use JSON to encode geographic data. It is neither a GeoJSON file nor a GeoJSONL file.

How can we tell that? By reading the GeoJSON standard - the standard is written in very simple English and is easy to understand. Your file has things in it like this:

"features": [

{

"attributes": {

"KAEK": "050097319007",

"AREA": 952.72

"geometry": {

"rings": [

[

476096.74,

4202590.96

... but there is no such thing as a "rings" in the GeoJSON standard. In fact, even if you're unwilling to read the GeoJSON standard you can search that web page and see the word "attributes" does not appear anywhere in the standard. GeoJSON does not use that word.

So what you have is neither a GeoJSON file nor a GeoJSONL file. It's a "json" file in the generic sense of data organized by some scheme known to the author of the software that produced it and perhaps supported by some of his friends.

Whatever it is, it doesn't seem to be widely supported. I tried importing it using GDAL and that was no go. I don't know what version of GDAL I have installed on the machine I used, but if it's not something GDAL from a couple of years ago didn't support (it's either that or the most recent version on my machine), then the organization of data in your json file is not exactly mainstream.

----

Some notes on the GeoJSON standard...

1. The standard does discuss rings, but only as a way of describing the structure of the fixed GeoJSON Polygon type, not as any sort of introduction of an alternate type. I get the feeling that whoever wrote the software which generated your .json file may not have been a native English speaker and thus got confused by that technical discussion about whether they could invent and use a "rings" type. Either that or, maybe, your file dates from an era before GeoJSON when people made up all sorts of things on the fly.

2. In the "you can't make this up..." department, the earnest authors of the GeoJSON standard after setting forth a more or less well defined standard go on to say, in effect, that if you don't like the standard you can ignore it, by writing:

Members not described in this specification ("foreign members") MAY be used in a GeoJSON document. Note that support for foreign members can vary across implementations, and no normative processing model for foreign members is defined. Accordingly, implementations that rely too heavily on the use of foreign members might experience reduced interoperability with other implementations.

Well, it's not much of a standard if you can do something in it that depends upon telepathy for interoperability.

3. But they do redeem themselves, at least in part, by writing:

Implementations MUST NOT extend the fixed set of GeoJSON types: FeatureCollection, Feature, Point, LineString, MultiPoint, Polygon, MultiLineString, MultiPolygon, and GeometryCollection.

So... no "rings".

---

Bottom line: certainly not a bug, just a file that is not one of the standards for interchanging geographic data that Manifold (and, apparently, at least reasonably recent versions of GDAL) supports.

Dimitri

7,592 post(s)

#04-Oct-25 08:09

but there are no problems to load this json-file into QGIS or Globalmapper

So what? QGIS ignores X/Y ordering in the EPSG standard. Should Manifold do such a wretchedly amateur thing as well just because Q does it?

GDAL as of a few years ago doesn't support it and given the very wide range of niche formats that GDAL/OGR supports that's an indication that whatever this file is, it's not mainstream.

There are pluses and minuses for ignoring standards. The Suggestions web page I think has a useful discussion of those:

Requests to Ignore Standards
Manifold users will occasionally encounter files claimed to be in a standard format where the file does not accurately utilize the standard. For example, there are many programs that can be used to write "shapefiles" which do not correctly write shapefile format, and there are images said to be in "GeoSPOT" format that are not written in accurate GeoSPOT format. Manifold will at times receive requests to alter Manifold dataports so they will read such non-standard files.
There are conflicting philosophies about staying true to a format standard. The philosophy which experienced professionals normally insist upon is to honor standards strictly and accurately as a protection against importing or passing on junk data. A more casual philosophy says if something can be extracted from a file even though the format standard is not followed then do it. The second philosophy is often more convenient in the short term, but can lead to catastrophes in the long term. The first philosophy avoids poisoning data in a way which later on is very costly to remedy, but it can be less convenient in the short term.
Manifold tends to follow the first philosophy, of taking format standards seriously. However, if there is a large body of data that systematically violates a format (for example, a large collection of data made available by a government), the Manifold team is willing to bend the format definition a bit and allow such data. If you need such a relaxation of standards, the best way to argue your case is to provide a URL or other information that documents the existence of a large body of data in that "broken" format.

The reason that professional people who were creating computers and software evolved standards is because they had the practical, professional experience to know that standards help interoperability and that responsible conformance to standards helps avoid wasted time, helps avoid chaos, and helps increase productivity.

Less experienced people sometimes disdain standards because of short term thinking. They don't realize that cheating on standards may be easier sometimes than putting in the effort to support a standard, but only at the cost of much greater difficulty in the future.

You could argue, I suppose, that the particular file at issue so wildly disregards the GeoJSON standard that it is not an example of cheating a standard but is an example of a completely different format that also uses Javascript object notation (JSON).

OK, fair enough. In that case whether it makes sense to support it is driven by the considerations that the Suggestions page helpfully sets forth:

Suggestions for New Formats
Manifold frequently receives requests to add a new format to Manifold System for import or export. Manifold is always willing to consider adding new formats. There are six main determinants as to whether a new format will be added:
* Is this a GIS, DBMS or Spatial format? People sometimes write asking for formats that have nothing at all to do with spatial work. In other cases, people ask for technical notions that are not themselves formats but are something else. The classic examples are GML and XML, which are not themselves formats but are languages in which a wide variety of different formats can be created. In such cases, the specific format desired must be known.
* Does Manifold have full and complete technical documentation on the format? If Manifold has publicly available documentation (such as a URL) that completely defines the format it becomes much easier to consider. Send such a URL or document to increase the chances your request will be implemented. Note that an API which claims to read/write the format but which operates as a black box is not information on the format itself. Please do not send confidential information.
* Is the format a difficult one or an easy one to implement? Easy formats that are well-documented usually will be added rapidly.
* Has Manifold had requests for the format? If Manifold has had very many customer requests it is more likely Manifold will add a format even if it is difficult to implement. For an easy format that is well documented Manifold has in the past added formats with only a single request.
* Are there samples available of data in that format? The more complex the format, the more samples will help to make sure the dataport works correctly. If you send in a URL to a page that has plenty of samples the engineering team will know that any new dataport can be tested. If there is no way to test the dataport it is unlikely engineering resources will be committed.
* Is anyone actually using this format? Citing a significant collection of data that would be made available by this format answers the question. People and organizations invent new formats all the time that end up going nowhere. There is little chance a format will be implemented if no one actually uses it.
Users sometimes write "Can you add XyzGIS format? Their home page is www.xyzgis.com." This is not helpful because unless a very large number of requests for that format are received Manifold staff will not search the site for documents that might define the format. Users will also sometimes write suggesting a new format and pointing to an API that claims to provide an interface to the format. That's not helpful since such APIs almost always require agreement to terms and conditions. The cost of reviewing those on a legal basis is usually greater than simply implementing direct support for the format, and rarely are those terms acceptable to a competitive, commercial company like Manifold.
If you would like to advocate a new format, you increase your chances greatly by doing the detective work to find a solid technical description of the format and by providing some samples. Many of the formats in Manifold were added at the request of a single advocate who patiently located the required information and forwarded it to the Manifold team for implementation.

I presume that anybody who seriously gives a hoot about this format will find the time to read and apply a few short words of advice like the above.

Likewise, anybody who gives a hoot about their fellow users I hope will not do their fellow users the discourtesy of suggesting that anybody's time be wasted to support some format that virtually nobody uses or which otherwise is marginal by the above criteria.

Add to the above, if anybody really wants this new format they should first see if recent GDAL/OGR releases support it. If GDAL/OGR supports it, 9 does.

The current build supports GDAL 3.10.x. It's very rare in my work that I encounter data I want which is in such a niche format that 9 doesn't support it but GDAL does, so I don't bother keeping the latest GDAL loaded on my machine. But if you really want to use a new format right now it makes sense to see if the latest GDAL supports it. That is also a courtesy to your fellow Manifold users for two reasons:

a. If even the latest GDAL doesn't support it, you know it's such an extremely niche thing that you probably don't want to push it over things that most users want. That's just basic courtesy to other users.

b. If the latest GDAL does support it, then Release 9 can import it through GDAL, same as applications like QGIS. After all, if you think it's OK that Q imports it, then you're not going to have an issue installing and updating a gigabyte of extra stuff, right? And if GDAL does support it, well, then there's no reason to harass your fellow Manifold users by pulling resources (including exploration of alleged bugs that are not bugs) for something they don't care about.

By the way, if anybody loves the idea of open source because with open source they can extend their GIS to support whatever format they want, well, heck, that also applies to Release 9.

The open source mechanism that allows anybody to add new formats is the use of GDAL/OGR as a format reader. If you want to add a new format to Q, you don't hack Q, you dive into GDAL and add a new format to GDAL. Hey, it's open source! You can do the same with Manifold because 9 is perfectly happy to use GDAL too if that's what you prefer.

Dive into GDAL, add your new format, and away you go. Manifold will be happy to use it. If you don't want to wait for the next iteration of GDAL or acceptance by the GDAL community of your alterations, do your own local fork (as people do), save it into the same path used for GDAL 3.10.x builds and away you go.