ThinkGeo.com    |     Documentation    |     Premium Support

PostGis ad hoc queries and hex wkb to bytes[]

#1

Hello,


I have been trying for a while to work with MapSuite Desktop edition as I inherited the code and a project from my predecessor. Looking through the code and through this forum I realised that MapSuite is not able (yet? correct me if I am wrong) to issue ad hoc queries in the PostGis server and from there to create Layers. It rather expects a View or Table as i have seen. This is very limiting as (a) you must either resort in creating tables on the fly and then call them via the PostGisFeatureLayer contructor or (b) creating views on the fly that is also ... ugly... In fact, the best would be to be able to get MapSuite layer diretly form custom queries or even better from stored procedures that return records/setof[]/table structures etc. So my first question is, am I missing something or is this really the case?


In the meanwhile I bypassed the PostGisFeatureLayer and I am using ad-hoc queries and stored procedures passing the returned "geometry/geometries" to MapSuite features like "Dim aPoint as new PointShape(<wellknowtext>wellknowtext)" . That works great and I probably understand why (if this is again the case) there is no enhanced PostGisFeatureLayer constructor that accepts addhoc queries or stored procedures i.e itterating through the ResultSet and creating Features is not that big deal.  However, trying to optimise my code I thought that it is better to return the HEX "well known binary" from PostGress/PostGis than the lengthy "well known text". In such a scenario, I could use the "Dim aPoint as new PointShape(byte[])" constructor. Well here is the question, before I reinvent the wheel, and write my own code to convert the HEX to unsigned bytes, is there any hellper function in MapSuite that does the conversion from HEX to byte/binary?</wellknowtext>


Thank you for your patience and for the help


Kind Regards


Yiannis



#2

Yiannis,


Thanks for your post and welcome you to ThinkGeo Desktop Discussion forum.
I think we got the ad hoc queries supported since last public release, I am not sure you are using the right version for it. This feature should be added for MsSql, Postgre, Oracle Dbs, see more details from following link:
gis.thinkgeo.com/Support/Dis...fault.aspx
I am sorry to say that we do not provided the APIs to convert Hex to byte, while I searched on the Google and found that this code snippet was provided in some site, see following website:
codeproject.com/KB/recipes/hexencoding.aspx
bytes.com/topic/net/answers/106096-hex-byte
Any more questions please feel free to let me know.
Thanks.
Yale

#3

Hello Yale, 



Thank you for the answer. Thanks for the effort you put as well to provide me for the links on doing the hex to bin conversion. I had already devised such a solution and I was just hoping that it might be part of MapSuite. I suggest you include the implementation for the HEX to byte conversion in one of your next releases since it is a very common horror story seen in code-sources over and over again, people to just consider streaming a huge wkt over the net as a natural way to do things. That has an impact on performance that may indirectly been attributed to your product without of course this to be the case. 



As for the main issue. It is my understanding from the link you sent me that if I want to use an ad hoc query I must "intercept" one via the event and essentially "re-write" the parameters i.e query string (statement), query type etc. As I was not aware of this implementation I just did what I described earlier on my post i.e issuing a normal sql and itterating through the return geometries creating Features adding them to an inMemorylayer. So the questions now are two:  

1) What are the advantages of using the MsSql2008FeatureLayer than what I did 

2) Why going through the event and not via a normal constructor? Without having work with the new version I assume that I still need to create a "new" MsSql2008FeatureLayer maybe with a fake "query", then to intercept the event and then to re-write the statement. 



Looking forward to hearing from you 

Kind Regards 

Yiannis



#4

Yiannis,


Thanks for your input and suggestions, I appreciate it very much. I will report this to our development team with some Gemini issue added, hope we can get it added later in our products.
1) I think it will be the same if you return all the features from the SQL server and store them into InMemoryFetureLayer with using the MsSqlFeatureLayer directly if no special reason stops us to do this. While in some special cases we cannot do this in this way, for example:
Case 1: Data is too huge to store in memory. We only need to get the features within the current extent dynamically when we use the MsSqlFeatureLayer, while when we try to store it in InmemoryFeturealyaer, it has a cut edge demand of memory usage when very huge number of records involved.
Case 2: Performance requirement. When we use the MsSqlFetureLayer, we can get the performance boost with the table indexed. Of course, we can do it in the same way for the InmemoryFeatureLayer by calling the API BuildIndex in InmemoryFeatureaLayer, while it always need some time to get it indexed built when some large data involved.
Case3: Data can be updated or added/deleted at the same time when the application is running, I believe it is possible while very difficult to get the data updated instantly when using the way you mentioned.
2) Basically the principal reason for this event is letting user have some way to trace what sql statement sent to the server when facing some issues, also this event can do some advanced stuff dynamically which cannot be implemented using normal ways because its flexibility of sending out the sql statement and letting the user change it to what they want dynamically.
Any more questions please feel free to let me know.
Thanks.
Yale

#5

Yale,



I can see your points and thank you for your response. What I understand is that the MsSqlFetureLayer/PosGresFeatureLayer has the "ability" to feed back automatically the "extent" of the map, thus any query is spatially constrained within this extend while in my "solution" I have to manually pass the extend as a parameter to my custom queries and always do something like:



Dim cmd As Npgsql.NpgsqlCommand = New Npgsql.NpgsqlCommand("select astext(pos_point) from core_pos_info where st_contains(ST_GeomFromText('" & searchArea & "', 4326), pos_point) = true", conn)


Where searchArea is the extend of the MapSuite viewport expressed as a shape. In anycase I will download the updated version and give it a go. I hope I will come back with some good "results" and/or "examples"


 


Thanks again


Yiannis



#6

Yiannis,


Thanks for your post and feedback.
Just go ahead and have a try on the latest version and please feel free to let me know if any more questions or ideas.
Thanks.
Yale