forums.silverfrost.com

[Kenneth_Smith]

Another thought.

Have you tried exporting the x y arrays that define the border in the call to %pl to a text file (immediately before the %pl call), and then importing that text file into Excel and plotting the data in an X-Y plot? This would confirm if %pl is correctly plotting the data that is input into it (or not). If the Excel plot is the same as the %pl plot � with crossed lines then there is an error in your code associated with reading the input data and forming the arrays that are passed to %pl.

[Martin_K]

Thanks for your tip Ken!
I will inspect it as soon as I will have more time, since currently we test
a complex measuring system which we mounted on a measuring boat used for mapping of river�s bed (on Danube river) containing different sensors, sonars and GNSS equipment. I have very limited time which I can dedicate to programming.

[Martin_K]

Ken,

thanks for your inspiration! I spent three nice hours in last night for checking where could be the problem regarding the joining of points with lines in my code using %PL command.

I coded it once again using a graphic Trimble Business Center utility and also Excel and definitely can say the following: neither my code nor the command %PL have the problem with respect to joining the points with lines (they do not cause the cross-line joining due to their potential internal problem)!

Definitely, the problem can be attributed to either ArcMap software of ESRI (which in some areas incorrectly split polylines to points. I will check it) OR the source of data (cadastre) has some inconsistency (incorrect order of points with respect to their coordinates). I will try to find out how to fix it. In the meantime (as time allows me) I will also strive to implement your last modification (with the direct access to a file containing a large number of arrays and their indexing) to be able to show the DX,DY values in the graphics when pointing cursor over a grid point!

Thanks again!

Martin

[Kenneth_Smith]

Marting,

The really important thing about using binary direct access is getting the record length correct. This demonstrates the idea.

Ken

[Martin_K]

Ken,

I identified the problem with the joining of lines! The problem was/is in the
ArcMap export, which for unknown reasons incorrectly sorts the vertices (vertex points) created after splitting polylines into discrete set of points.
Interestingly, it can be observed in a few areas only (still stranger behaviour).
Anyway, I manually corrected the export of border points and now, in my code using the %PL command everything looks OK (see the problematic part of the graphics below, now it is OK, no cross-lines are present).
[url]

[/url]

Thanks again for your inspiration!

Finally, I can move to the implementing of your new code!

[Martin_K]

Ken,

I finally again can devote some short time to continue my development. In your code above, there is the function LOCATE_I_J_in_TABLE(I,J,N), where N is size of an NxN matrix. It also contains the code:

[Kenneth_Smith]

Martin,

If you have a matrix of N rows and M columns, with N =2 and M =3

(1,1,) (1,2) (1,3)
(2,1) (2,2) (2,3)

If you write each element of the N x M matrix to file one element at a time BY ROW ORDER, you get:

1 (1,1)
2 (1,2)
3 (1,3)
4 (2,1)
5 (2,2)
6 (2,3)

Notice that the first three elements span M columns as does the last three elements. With this arrangement, the position of element (i,j) in the above table is:

[Martin_K]

Ken,

many thanks, now it is clear (by the way, there is a misspelling error, it should be Pos(2,3) = (2-1)*3 + 3 = 6).

Again - thanks, I continue.

[Martin_K]

Ken,

I still have a problem with the locate_i_j_in_table(i,j,n) function.
I have the matrix of 204 rows x 428 columns. This I re-rewritten according to ROW order to a binary direct access file containing 87312 rows (lines) with DX,DY values (each of them 8bytes long, so RECL=16 for each row/line).

The code

[Kenneth_Smith]

Martin,

The X,Y data that define the grid can easily be stored as two arrays, as before � with no memory problems. You don�t need to include this data in the direct access file.

For a given cursor position you can interrogate X and Y arrays to find the nearest grid point at X(i) and Y(j) again as before, and once you know i and j, then read the appropriate line in the direct access file. I think you are making your program too complex.

You may want to consider changing the direct access file from UNFORMATTED to FORMATTED. This would allow you to read the file in notepad for example.

If you want to run your code with the direct access file FORMATTED, you need to pay attention to the format codes for both the write and read operations � they must be the same, and the number of characters they write must be the record length.

I will post a modified version of the direct access example above using FORMATTED access shortly.

Ken

[Martin_K]

Ken,

just for clarification:

I created the binary file containing the binary DX,DY values (and only DX,DY values) separately in a single separate program to have the binary file available for any additional purposes in the future. The binary file was created from the ASCII file containing the X,Y,DX,DY arrays, where only DX,DY values were written to the binary file. So both file have the same number of lines (87312), but binary file contains only DX,DY arrays.

So, my graphical program opens a sequential (ASCII) file containing the X,Y, DX, DY arrays to plot them in a graph and upon reading in the whole X,Y arrays from the ASCII file I also open the binary file where I want to read in the corresponding i,j record of DX,DY values determined from the X,Y arrays of the ASCII file to be able to show the X,Y,DX,DY values at the cursor position iwhen moving with the cursor n the graphics.

[Kenneth_Smith]

Example as promised.

[Kenneth_Smith]

Suggest you modify your code to include a write to a direct formatted file immediately after your write to the existing direct unformatted file. You will then be able to check that the data written to the binary file is as expected and looking at the "equivalent" text file.

Unformatted direct binary read/write will be faster than formatted, but it's difficult to find the bugs.

Ken

[Martin_K]

Thanks Ken!

I will review it and try to implement!

[Kenneth_Smith]

OK I see your issue now, and it does not appear to be with the direct file.

Minloc should return a value between 1 and 204 for one axis and between 1 and 428 for the other, and there are 204 x 428 = 87,312 records in the binary file.

I don�t understand how minloc can return a value of 87,312 - unless you have read 87,312 points into the X and Y arrays from your input ascii file?

You only need 428 and 204 sets of sequential "axis" coordinates in these arrays.

Ken