Hello Mathieu,
I trust you are well. (France played well yesterday!)
Attached is the most recent version of our generic Land Use Survey in ODK format. It currently automatically calculates the surface area of the Geoshape recorded in the form.
Q: Could you advise on the ODK code we should use to add an automated calculation for the 'perimeter' of the same geoshape? C1.Land_Use_Survey_Generic_v7.xlsx (48.8 KB)
Returns the distance, in meters, of either:
a nodeset of geopoints
*the perimeter of a geoshape*
the length of a geotrace value
It takes into account the circumference of the Earth around the Equator and does not take altitude into account.
I am fine thank you ! Hope you too.
I will spend some time tomorrow during a train trip on ODK (Central french translation to complete) I will try to understand the origin of the problem.
Could you provide some raw string data for both working and not working polygons ? I will see if we could automatically clean it or at least use it.
I had a test to handle cases when geo strings contains '; ' as separator instead of the only semicolon.
This problem occurs sometimes and @davidbaines faced it here :
In such cases, point can be considered as a space-separated list of values with one more space and one more column index. geoshape2wkt.xls (8 KB)
What I'd like to do is be able to collect 1 to many geotraces or geoshapes, and wrap those up as MULTILINESTRING / MULTIPOLYGON outputs (and then at the end combine all point/trace/shape to a GEOMETRYCOLLECTION)
I started with @mathieubossaert's example, adding a repeat to allow multiple traces, but when I try to calculate the string inside the trace repeat, it uses all line vertices from every line, (so if line 1 = A to B to B and line 2 = line D to E, then it returns line 1 = A to B to C to D to E and line 2 = A to B to C to D to E)
I think the solution lies in how to refer to / constrain particular repeat elements (i.e. only take child repeat coordinates if their parent repeat instance = this instance) unless there's a simpler approach to the problem altogether?
Combining points to MULTIPOINT was simpler, and combining the MULTIPOINT with a LINESTRING etc to a GEOMETRYCOLLECTION is also simple.
Yes, what I'd like to do is have repeats for each geotype (point/line/shape) so the enumerator can add as many as required (eg place a point for all corrosion hole anomalies, trace a line along each affected pipe section, draw a shape around all affected areas).
Then bundle each type into a MULTIxxx, and bundle those into a collection, such that the parent submission has all the geo elements wrapped up in a single string. This means I can handle having any number of each geotype finding and won't have to pull the child repeat elements to get the details (unless they also have additional fields associated with them) as they're in GEOMETRYCOLLECTION in the parent form.
The part I'm stuck on is how to create the MULTILINESTRING and MULTIPOLYGON by referring to the particular repeat instances. I have already done the MULTIPOINT and GEOMETRYCOLLECTION steps.
From the above example, the correct output for the MULTILINESTRING would be:
Hi @mathieubossaert geoshape2wkt.xlsx (10.1 KB)
,
I am also looking for a solution. if you see the attached form. the output I am receiving from two repeated geoshape form is as Multipolygon((A B, C D, E F, A B, I J, K L, M N, I J)).
where A,B,C etc are longitude and latitude.
problem: I cannot group the output of a single repeated loop.
What I want:- Multipolygon(((A B, C D, E F, A B)), ((I J, K L, M N, I J))).
your help would be great for me.
Thanks @mathieubossaert! This is the key that unlocked what I was trying to achieve: selected-at(${geo_polygon},${index_polygon}, I was reading the docs and knew this was the direction I needed to go in but hadn't worked it out.
The output is exactly what I was chasing, the ability to construct a collection of any number of different geo elements.
In the repeat_count field in the example file @mathieubossaert has attached, the count is eg ${numpoints_polygon}. This will not throw an error in Enketo, and will function in Collect, but it will throw an error message on validation in Collect without pointing anywhere specific and preventing save/submit.
Sorry, form save failed! java.lang.Double cannot be cast to java.lang.Integer
Changing the repeat_count to eg int(${numpoints_polygon}) will fix this in Collect
the solution given in above thread works absolutely fine for smaller polygons i.e. number of points less than 40-50 in a single polygon.
APP freezes when it exceed 100 points which is above 1 acre in area.
we are mapping farms having different shapes (not necessarily square or rectangular) to capture that irregular shape we are collecting points at 3 seconds interval.
Any alternative solution for this or better to write a function at server side to convert from ODK shape to WKT?
value represents an array of submissions. Submissions are key value pairs with nesting for groups and references for repeats.
You probably would need to do another post-processing step but depending on your needs, this could be a good starting point. You can access it with pyodk with client.submissions.get_table(form_id=<form_id>, wkt=True) (see get_table example here) and with ruODK using geo_wkt.
You can also access it directly with: https://<server>/v1/projects/<projectID>/forms/<form-id>.svc/Submissions?$wkt=true
If I want to get a response in-browser I usually copy the URL from the "Analyze via OData" button on the Submissions page and add /Submissions?$wkt=true. Unfortunately, there's one more step which is that your browser needs to request a JSON response. I use this browser extension to set the Accept header to application/json. We generally expect users to get this representation programmatically but it can be helpful to see in-browser when testing.
Apologies, I think I have missed something here, but the returned value for polygons etc is in WKT format when queried via OData & Powerquery with the default svc URL, and displays in Central as WKT also but without SRID=4326;. Is this different with pyodk & other methods?
eg for an ODK polygon which would be (and is this format in the CSV) -38 147 0.0 0.0;-39 147 0.0 0.0;-39 148 0.0 0.0;-39 147 0.0 0.0;-38 147 0.0 0.0
is returned as SRID=4326;POLYGON ((147 -38 0, 147 -39 0, 148 -39 0, 147 -39 0, 147 -38 0))
No, it's just confusing. The default format returned as part of the OData JSON is geoJSON because that's what the OData spec defines. Powerquery transforms it to WKT. I hadn't thought about this but you might be able to use Excel/PowerBI connected to OData as part of your data pipeline depending on what you need to do next with WKT.
The Central frontend uses the OData JSON request with $wkt.