Subscribe to this thread
Home - General / All posts - Reference for arguments in functions?
tonyw
635 post(s)
#27-Aug-21 18:19

Question, where do I find reference to possible values for arguments in functions?

For instance this function CoordConvert(<converter>, [Geom]) What are possible values for "converter". I have searched the manual with no success. I can't find any examples where a value has been pasted in for "converter".

I may be on the wrong path completely. My task is simple, it's to add Lat and Long to a table. The client wants Lat and Long for points. My original drawing is projected in BC Albers (CRS 3005). I added the points. I added two fields to the table "Lat" and "Lon" and tried to populate them. The closest function I can find is CoordConvert(<converter>, [Geom]). The description is "Converts a geom from one coordinate system to another. The function takes a coordinate converter object and a geom value, and returns a new geom value", seems the closet to what I need. However I don't know what to put in for Convert as the "function takes a coordinate converter object". What is the object?

In another tack I created another drawing but projected in Lat and Long. I copied the points from the drawin projected in BC Albers and pasted to the Lat and Long drawing. The lats and long show in the info pane but I still can't populate the table. I tried Transform but run into the same problem of what value to put in for "convert", if that's even the correct function.

I tried finding functions with the word "latitude" but none come up.

A feature suggestion, hovering over or a right click on an argument to bring up a list of possible values? That would help me immensely. Much like how it works in Excel, the possible arguments are described and effects on the results.

Thanks

sknox62 post(s)
#27-Aug-21 19:11

I think you need the CoordConverterMake function which returns a <converter> object. The values after the : are the return type of the function. I think that in turn needs ComponentCoordSystem which is in the General SQL topic. I found it difficult to make the leap from CoordConverterMake(<target>, <source>) to ComponentCoordSystem(<component>) : <system>.

So, in summary, I think you need:

CoordConvert( CoordConverterMake( ComponentCoordSystem( targetdrawing/image), ComponentCoordSystem(sorucedrawing/image)),[Geom]);

I personally would find examples useful as well, but if you search the forum, there is often guidance and sql code as examples e.g. here. But these often date with changes to the API so some easier reference would be helpful.

Mike Pelletier


1,906 post(s)
#27-Aug-21 19:12

Without answering your question, here's a couple queries that add lat and long. Search for "computed fields" in the manual and scroll to the bottom for examples.

ALTER TABLE [AddressT] (

ADD [LAT] FLOAT64

WITH [[ VALUE @converter TABLE = CALL CoordConverterMake(CoordSystemDefaultLatLon(), ComponentCoordSystem([Address])); ]]

AS [[ rounddecs(VectorValue(GeomCenter(CoordConvert(@converter, [Geom]), 0), 1),6) ]]

);

ALTER TABLE [AddressT] (

ADD [LON] FLOAT64

WITH [[ VALUE @converter TABLE = CALL CoordConverterMake(CoordSystemDefaultLatLon(), ComponentCoordSystem([Address])); ]]

AS [[ rounddecs(VectorValue(GeomCenter(CoordConvert(@converter, [Geom]), 0), 0),6) ]]

);

danb


1,822 post(s)
#27-Aug-21 21:41

My process is usually first to search the manual on the function you are looking for: CoordConvert

Looking at the results in the manual I see:

CoordConvert(<converter>, <geom>) : <geom>

Converts a geom from one coordinate system to another. The function takes a coordinate converter object and a geom value, and returns a new geom value

I see from this that I need a coordinate converter object and so I look for this and find:

CoordConverterMake(<target>, <source>) : <converter>

Takes the definitions of target and source coordinate systems (in that order) and creates a coordinate converter object. Coordinate converter objects are treated syntactically like a table, so we have to write

CALL CoordConverterMake(...)

Returns NULL if an coordinate converter object cannot be created. That can happen due to an impossible combination of parameters in either of the coordinate systems.

Quite often however I dont understand how to put all this together so I would then search for an example on the forum or failing that think of an existing transformation that would involve a coordinate system transformation and press Edit Query to have a look at an example of how it is done there.


Landsystems Ltd ... Know your land | www.landsystems.co.nz

tjhb

9,824 post(s)
#27-Aug-21 22:22

Excellent description Dan. Similar to what I try to do.

My two cents: there's no future in trying to understand syntax on a case-by-case basis. It's not atomic.

What's needed is to learn how everything fits together.

Mainly by reading stuff you don't immediately need to know, but might use tomorrow.

Reading through the all of the SQL Functions topics is a good start. Hardly any of it will stick the first time, there's too much for anybody, but by the fifth or seventh casual skim through, you start to know where to look, even in a hurry.

That said, it's not hard to imagine a diagram that would help.

Manifold 8 had a hierarchical object model, and a corresponding diagram. The diagram was probably of less use than it seemed to be, day to day, but it helped give initial confidence.

Manifold 9 has a very thin object model (to the extent that it is hardly one at all, rather a family of functions), but I think tonyw has pointed out that within SQL9 syntax, some arguments are very object-like, to the extent that we might benefit from a map here too.

It could be a very incomplete map. Little point in including arguments like <table> or <drawing> for example--unless as a reminder where one must be used, not the other.

tonyw
635 post(s)
#28-Aug-21 03:10

Thanks everyone for the suggestions.

The ironic thing is if I open the drawing, Alt-click on a point, in the Info Pane > Coordinates I can see the Lats and Longs. So the Lats and Longs are there somewhere but not easily accessible.

I spent a hour and a half of trying different things, searching and reading before posting my question (thanks for the replies). I ended up copying and pasting the Lats and Long values one by one from the Info > Coordinates pane to the two fields I added to the Table via the Info > Values pane. I have 8 points so only needed to do 16 copy and pastes.

tjhb

9,824 post(s)
#28-Aug-21 08:40

Is that it?

No thoughts in response to the rest of us?

Sheesh.

tonyw
635 post(s)
#29-Aug-21 06:17

Is that it?

No thoughts in response to the rest of us?

Sheesh.

Tim, was that a comment to me? I'm not sure, many people were responding to other people. Who is your comment for?

If it was for me, I apologize for not responding in more depth. I got the info the client, a bit late, then headed off to the field. I will digest and respond more, it will take awhile to digest as I'm wait of my league when it comes to programming. My programming days were Fortran with punch cards and submitting jobs to central computing then coming back in a few hours or next day for the results (or find out there are syntax errors an the job never ran).

tjhb

9,824 post(s)
#29-Aug-21 06:20

Yes, it was. I thought that after all the thoughts others had put in, in reply to your post, you could at least have offered your own thoughts out loud.

Riivo has basically answered the question, practically speaking (you might disagree), but I'd still be very interested to know what you think.

Your question was very good.

steveFitz

315 post(s)
#30-Aug-21 02:15

I got the info the client, a bit late...

While I appreciate that the post is about using M9 effectively, when the crunch came why didn't you export your file to M8 and export it back into M9 with the intrinsic fields for lat and lon ticked to export? Was it because you had specific formatting, etc.?. (I guess that some export formats like shapefile may corrupt your data by truncating, etc.) I assume you have M8?

adamw


9,738 post(s)
#31-Aug-21 13:25

The ironic thing is if I open the drawing, Alt-click on a point, in the Info Pane > Coordinates I can see the Lats and Longs. So the Lats and Longs are there somewhere but not easily accessible.

Regarding this, the values you see in the Coordinates tab are coordinates of a geom value. You can access the coordinates of a geom value in a query using GeomToCoords function. The function takes a geom value and return a table of coordinates. Since it returns a table, you need to call it using CALL. If you are working with a SELECT, you can insert the table into where the geom was using SPLIT. Here's an example:

--SQL9

SELECT [mfd_id]SPLIT CALL GeomToCoords([geom]FROM [states];

We are preparing a new version of the documentation specifically for SQL. It is similar to the API doc that we have for scripts and will include an example for each function and each statement.

tonyw
635 post(s)
#31-Aug-21 17:50

Thanks Adam. I've done some trial and error with the SQL using SELECT[mfd_id], SPLITCALLGeomToCoords([geom]) FROM[states]; as a model in my .map project. I'm getting "cannot parse query" error. I will create a demo .map file and post for comments.

SQL looks like a great tool. I have tried to learn it, have bought Art's lessons and have bought books, but I don't use it enough for it to stick. The most I often do is GeomArea(<geom>) / 10000 to arrive at hectares or concatenate and cast to create labels. Beyond that it's a really deep rabbit hole with more questions than a solution.

However I will persevere by deciphering any examples in the manual and what people kindly provide. The documentation you mention will help especially if you have a demonstration .map file so we can see what goes where and where we can see results of queries. I'm constantly hitting the "cannot parse query" wall. It's really hard to know what is a function, what is a field name, and what is a valid argument. Coding by trial and error is probably not the way to go but that's all I have to work with. Going down the rabbit hole, it never dawned on me that <converter> was another function and not one of several valid arguments which was my hypothesis. I admire those in the forum who can use SQL with ease. I'm really trying to use Manifold 9. The learning curve is steeper than the traction I have to climb. I'm at a disadvantage because I don't have a programmer mindset. I work by looking at examples of SQL, form hypotheses of how it is to work, try it, then keep trying.

adamw


9,738 post(s)
#01-Sep-21 12:50

Thanks a lot for your perseverance.

We are working to improve the error messages right now. Agree the current ones are not much help, they tell you too little. As I said, we are working on the documentation as well. We think we can do a lot to make SQL more approachable, and are planning features specifically for that (syntax highlighting, helper functions for areas that are doable but take too much code, etc).

PS: Do post the demo MAP file, we'll find the cause of the error message.

tonyw
635 post(s)
#02-Sep-21 21:28

Here is a demo map file. CRS is BC Albers (ESPG 3005). The two jpegs show the results of my queries. I started the project with CRS BC Albers and also made a drawing with Lats and Long then copy and pasted the 9 demo points so that the drawing was in Lats and Long thinking I could access the Lat and Long info.

With Mike's multi-line Query I got the number "1" as a result. See the jpeg Alter Add Table.jpg with the drawing projected in BC Albers. When I applied the query to the table in Lats and Long, the query successfully added two fields Lat and LON but did not populate the two new fileds.

I had better success with Adam's Split Call which generated a table of lats and long combined in one field. (See jpeg Split Cell Query in Command Window.jpg)

I went down some deep rabbit holes with sknox's object within an object. I didn't know how to structure a query to apply the approach so don't have results to share.

SteveFitz: I never thought of using M8 and it's intrinsic fields. I ran out of time to try more and I was working in M9 figuring there had to be a way because Lats and Long are basic GIS concepts. It had to be there somewhere to be simply called up in m9.

There was discussion in previous threads about why intrinsic fields as used in M8 are not supported in M9, that intrinsic fields are simply computed fields so create computed fields. It would be nice in M9 to not need to repeatedly write SQL to compute fields for values that are common in GIS such as areas and lengths. I know, the argument is what unit of area or length should Manifold generate? Acres, hectares, metres, feet, yards, nautical miles, etc. What if the units could be arguments in a function? Area(<units>, precision)? There is probably some consideration for the native projection of the drawing too. I'm confident that Manifold can work with native projection and output measures in the user's desired units.

Attachments:
Alter Add Table.jpg
Derive Lats Long in M9.map
Split Cell Query in Command Window.jpg

steveFitz

315 post(s)
#07-Sep-21 00:20

I followed Mike Pelletier's advice and found the example near the bottom of the computed fields page and ran the the SQL on your table and drawing. It seemed to work.

For me the table place holder in the example, [T2], was a bit confusing because in my mind 'T1', 'T2', etc. are often used to refer to sub query tables, so [Drawing Table] would have made more sense to me.

ALTER TABLE [Points Lats Long Drawing 2 Table] (

 ADD  [Longitude] FLOAT64

  WITH [[ VALUE @converter TABLE = CALL CoordConverterMake(CoordSystemDefaultLatLon(), ComponentCoordSystem([Points Lats Long Drawing 2])); ]]

  AS [[ VectorValue(GeomCenter(CoordConvert(@converter, [Geom]), 0), 0) ]]

);

ALTER TABLE [Points Lats Long Drawing 2 Table] (

 ADD  [Latitude] FLOAT64

  WITH [[ VALUE @converter TABLE = CALL CoordConverterMake(CoordSystemDefaultLatLon(), ComponentCoordSystem([Points Lats Long Drawing 2])); ]]

  AS [[ VectorValue(GeomCenter(CoordConvert(@converter, [Geom]), 0), 1) ]]

);

Is this what you wanted?

tonyw
635 post(s)
#12-Sep-21 18:34

Thanks Steve

I will try to duplicate your SQL in my map.

adamw


9,738 post(s)
#13-Sep-21 16:22

Sorry for the delay.

The query in the first JPG (Alter Add Table) returns 1 correctly, this is the result of the last statement, the last statement is ALTER TABLE, it returns either success or failure, 1 is success. The computed fields do not work because the second coordinate system passed to the converter is wrong: you are calling ComponentCoordSystem on a table, the table may have multiple geometry or tile fields, it does not have a coordinate system as a whole. You should have called ComponentCoordSystem on the drawing.

That said:

(1) Since you said earlier that you already see the desired lat/lon values in the Info pane, you don't need to convert coordinate systems, you can use the value of the 'Geom' field without conversions.

(2) If all you are interested in is points, you don't need GeomCenter or GeomToCoords either, you can just take the geom and get its first coordinate using GeomCoordXY.

Example query:

--SQL9

SELECT [Point Number],

  VectorValue(GeomCoordXY([Geom], 0), 0) AS [Lon]

  VectorValue(GeomCoordXY([Geom], 0), 1) AS [Lat]

FROM [Points Lats Long Drawing 2];

If you want to be able to access that as computed fields, here's an adaptation:

--SQL9

ALTER TABLE [Points Lats Long Drawing 2 Table] (

  ADD [Lon_n] FLOAT64 AS [[ VectorValue(GeomCoordXY([Geom], 0), 0) ]],

  ADD [Lat_n] FLOAT64 AS [[ VectorValue(GeomCoordXY([Geom], 0), 1) ]]

);

I used 'Lon_n' / 'Lat_n' because 'Lon' / 'Lat' were already taken. If you want to limit the number of decimals, use RoundDecs (we will make this unnecessary in the future by letting you control the output style for a field). If you want to allow lines / areas / multipoints, add GeomCenter. If you want to use a different coordinate system than the one used by the geometry values, add coordinate converter (see code from steveFitz).

adamw


9,738 post(s)
#13-Sep-21 16:25

As regards computed fields like area / length / lat + lon (of the center) / etc, we are planning to allow creating frequently used computed fields using a combo in the Add Field dialog. This would work like transform templates - sure, you can write a transform by hand, but you don't have to and can try using one of the existing templates. Same here, you will continue to be able to write the code for a computed field by hand, but you won't have to for some of the most common cases.

rk
464 post(s)
#28-Aug-21 20:54

It is possible to search functions from Query Builder by return-type.

start your search with : <

Manifold SQL has couple of opaque types (<converter>, <viewshed>, <watershed>, ...) that can only be obtained by some function and used in another. Otherwise, the values of those types are not inspectable (or printable).

Those values are treated syntactically like a table, so we have to write

VALUE @converter TABLE = CALL CoordConverterMake(...);

Attachments:
search_by_return_type.png

tjhb

9,824 post(s)
#28-Aug-21 23:17

Perfect. Simple, sufficient, and obvious now that you've said it.

Manifold User Community Use Agreement Copyright (C) 2007-2021 Manifold Software Limited. All rights reserved.