What is the general goal of the feature?
Have the choice to make a polyline and not just a polygon with type geoshape
What are some example use cases for this feature?
We use geoodk because this feature is already integrated here. However, the odk part is old in geoodk. We have developed a form to record cycling infrastructure. It can capture attributes of the route and, via type repeat, traffic junctions. There are attributes of the route, such as surface or type of cycling route, that can be captured at the beginning of a route. But there are also attributes that can only be detected at the end of a route (for example, damage to the surface or generally from where to where the cycleway reach). Between the beginning and the end of a section of the route are the traffic nodes, which can integrate all the information of the route by integrating into the same form (via parent-key). Because of the repeat function geotrace is not possible. It is also crucial to know on which side of the lane the cycle lane (s) lie. With geotrace this information is not possible. To be honest, I can hardly imagine that there are not other applications for this. Not all line-like objects that you could capture, can or do you want to run or depart.
The choice of making a polygon or a line would be great.
What can you contribute to making this feature a reality?
I am sorry but I can't coding. Just a user
I do not know exactly how Geoshape works as a code, but geoodk has its code on github as well. As an amateur, I'm probably mistaken, but can not you paste the appropriate code parts from geoodk into the code of odk?
Hi Dominik. Do you have an xls form you can share that implements the above data collection in geoOdk. I don't think I quite understand what you need.
Before geotrace and geoshape came along I used to support a hack on the server side in order to capture polygons and linestrings. You would specify the name of a repeat as say geolinestring_xxxx. Then inside that repeat you put a geopoint. When the server receives the data it would create the appropriate geometry in the table that stores the data from the form that contains the repeat. However a side effect of this was that it would also create the sub table with all of the individual points recorded in the repeat and all the answers to any other questions that were asked at each point. So you can record data at every point as well as the location and get a linestring. In your GIS you can then analyse at the level of the linestring along with the linestring level attributes, ie all the questions asked at the same level as the repeat. Or you could analyse at the level of the points with all the questions / attributes they contained.
I don't really use the above approach anymore as having the geotrace and geoshape types is more convenient. However would it be useful for your case?
Hi Neil
Thanks for the quick reply.
I think that your method will unfortunately not solve my problem.
We record the infrastructure of entire cities up to entire federal states with the form.
The infrastructure is often very fragmented and so we get many records. For example, for a small town with 20,000 inhabitants, I recorded around 900 records, ie individual sections of the route.
The problem is not with the form, but with ODK-Collect-Code. It simply lacks the function that is implemented in GeoODK-Collect.
Best regards
Dominik
Attached my table or xml file. The xls-form is strongly abbreviated so that it is easier to understand (the form is in German). But it will work.
The blue areas in the worksheet are for the coverage of the leg.
The orange areas for the detection of traffic junctions.
How the form works: As I said, the first blue part comprises all the questions that can be answered at the beginning of a section.
Then the operator starts and drives the route.
He arrives at a traffic junction on the route and starts the questions in the repeat-loop (orange area).
The operator continues and picks up the traffic nodes until something changes significantly on the route (for example, the cycle path ends and the cyclist continues on the road).
Now comes the last (blue) part of the form (look at the xlsx).
Here the appraiser evaluates the section of the route that is currently being used. For example, the operator evaluates and describes the damage on the track. Now he close the form and start the next section of the route.
With geotrace the operator could do this too. But the problem is, to stop the geotrace-track is error-prone. It would be better to make the line without gps, like it is possible with geoshape.
Ok I think I understand. You want to select the route using the background map and geotrace rather than gps? @Jon_Nordling may be able to help.
If I was doing this data collection for OSM I would record the nodes and a gps trace on the phone. Load both into JOSM create the ways automatically from the GPS trace and then adjust them for gps errors using base maps. Again I'm probably getting your application completely wrong. But i'd rather do the gps adjustment somewhere out of the rain.
Hi again
Thanks
Jon is not reachable since longer time
I just will put a line on the map with fingertips (like in geoodk) in odk.
Gps is not enough exactly for the work we made
Sorry for my bad english.
Thanks Neil for your help
Hi @LN I am unlikely to put my hand up to do the coding for this one. But the request makes sense to me. There doesn't seem to be a good reason bot geoshape and geotrace to work differently. Maybe the behaviour could be governed by additional appearance values
@Dominik, you want to be able to collect a trace manually by long pressing on a series of locations, am I understanding correctly?
This is part of the work planned as part of Collect geotrace and geoshape improvements. The goal is for geotrace to allow collecting a trace three ways: manually as you describe, by collecting current location at manual intervals and automatically at set intervals. Geoshape will allow collecting shapes/polygons in the same three ways. It would be very helpful if you could review the google doc linked from that first post and offer any feedback you may have.
That work has been stalled for a bit but @zestyping has picked it back up.
Hi
Yes, you have understood this correctly.
This will be a great feature.
If it is possible then please delete some parts of the coordinates by using type geoshape
I mean for example
49.97876; 7.876577;0.0;0.0
The last both 0.0 for height and for accuracy are superfluous.
And an other thing is that the x- and y-coordinates should swap.
Because if I read the csv over wkt in qgis. Then I have to use the xyswap tool from qgis to get the right location. Qgis 3.x didn't have this tool jet.
sorry for my bad english
Thanks for the reply and the good news
Regards
Dominik