If you have an example dataset that uses that schema definition, you can set you writer to use it as the Feature Type Definition

If you have an example dataset that uses that schema definition, you can set you writer to use it as the Feature Type Definition

 

Hey. I don't know if we got it right at the beginning. I edited the assignment. Can you please give me an example of how I should feed fme the schema that it compiles my data according to?

Thank you very much.

You could either completely create the GeoJSON in a JSONTemplater with that additional Layer object, or, write out the initial GeoJSON to a temp/staging folder with a feature writer, then read it back in with a feature reader (read whole file at once) and then insert the layers object into the geojson and save it out to the final location.

I would probably do the second option as it removes the need to potentially deal with edge cases of GeoJSON and on the surface would be a bit clearer as to what you’re doing. I can also see how the first option may be better in some scenarios

Hey. Thanks for the reply. If I understand correctly, the second solution is actually something like if I put two jsonTemplates behind me, where I work with the data ( body ) from the created template see attachment? I am considering the pythoncaller route, jsonTemplater seems like a fine way, but json schemas will be very complex, plus there will be links that will refer to another schema in the schema, try looking here: https://github.com/UASGeoZones/ED-318/tree/main/schema . 
If you look at the attachment, the complexity of the template is visible and this is only in the test so far, it doesn't include all the nested schemas - I don't know, maybe I can't use jsonTempater correctly.
With pythoncaller it might be easier to "slip" the schema to be stored somewhere locally, including nested schemas, I don't know... maybe, try to look at the attached fmwt, where featureCollection is the final output of JsonTemplater with a simple object. The test_json output is the pythoncaller processing. 
My point is, as the right way to choose, I would prefer to proceed with a transformer solution, first to exploit their potential, but in this case I find it very complicated and a lot of manual work to define in jsonTemplater.

Thanks for the answer

Another option is to use a JSONUpdator to update the geometry. You should be able to use a geometry extractor to get the geom as json and then insert the layer stuff into the geometry json object.

Once you have you’re geometry with the layer included you can then use that inside a json templator. This at least saves you having to try and extract the coords etc etc.

Another thing which might help you is the option to use json formatted attributes directly in the JSONTemplator. This avoids FME escaping all the special characters in the json.

 e.g., use fme:get-json-attribute("_geometry") instead of fme:get-attribute("_geometry")

This is a lifesaver. 

Also, as a rule I typically avoid using multiple subs unless I need to use arrays or I have a document with lots of differente objects with different schemas. 

Usually it’s just root (I’ll often use a sampler from one of the features (or a creator)) and then FEATURES or what ever it needs to be. This kind of thing also removes the need sometimes for having to use the process-features kind of stuff which I always have to look up how to use haha.

 

Another option is to use a JSONUpdator to update the geometry. You should be able to use a geometry extractor to get the geom as json and then insert the layer stuff into the geometry json object.

Once you have you’re geometry with the layer included you can then use that inside a json templator. This at least saves you having to try and extract the coords etc etc.

Another thing which might help you is the option to use json formatted attributes directly in the JSONTemplator. This avoids FME escaping all the special characters in the json.

 e.g., use fme:get-json-attribute("_geometry") instead of fme:get-attribute("_geometry")

This is a lifesaver. 

Also, as a rule I typically avoid using multiple subs unless I need to use arrays or I have a document with lots of differente objects with different schemas. 

Usually it’s just root (I’ll often use a sampler from one of the features (or a creator)) and then FEATURES or what ever it needs to be. This kind of thing also removes the need sometimes for having to use the process-features kind of stuff which I always have to look up how to use haha.

 

 

Hey. Thanks for the tip, I will try this transformer combination. This solves the geometry for me, however would you solve more complex schemes using a transformer? I am getting a lot of manual work out of this within the template. Or am I solving it wrong and unnecessarily complex? How do you solve complex nested structures such as the geoJson_example attachment. What would this template look like?
I was intrigued that you wrote that you use root and less SUB. I'm posting a printscreen of templates from the past, is this use wrong or unnecessarily complicated?

Unfortunately I can’t access the attachment so I couldn’t look at it directly but from the screen shots I do think there are probably too many sub-templates here. It does all depend on the data though. Like I said before, typically I use a sub template when I have an array (or I have multiple objects which need to be in the same document) or want to keep something separate for the purposes of clarity in the workspace.

You can nest just fine inside a single template - it’s really only when you have a mismatch in the number of elements in an array or multiple objects where you need an extra template. You kind of just have to experiment and see what works for you. But I guess only put in a new sub-template when you find you need to.

 

Hi, thanks for the answer.