My stab at an interface representing a LinearGeometry for Linear
Referencing is attached.
Note that I used only primitive data types and arrays of primitive
data types to maintain interoperability. In my final implementation I
would provide a wrapper to this that allowed the use of JTS geometries
and an Angle object as parameters.
The Sunburned Surveyor
On 6/21/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote:
I'll try to provide a simple Java interface for an abstraction of
linear geometries tomorrow. Then you guys can discuss it and tear me
apart. :]
The Sunburned Surveyor
P.S. - I want to wrap implementations of the LinearGeometry interface
in an Segment object. My Alignment object will be made up of connected
Segments objects. For the purposes of linear referencing and
stationing I don't really care if the segment is a circular arc,
straight line segment, multi-line segment, or complex curve. As long
as I can get some basic information from the object, like its length
and its begin and end point, I am happy.
On 6/21/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote:
> Bryce,
>
> Very good post. How do you keep track of all those ISO standards?
> (People wonder why I'm not "enthralled" about the process.) :]
>
> Bryce wrote: "I presume you would like to build linear referencing
> functionality on top of the 19107 geometric objects."
>
> Not quite. I want to build linear referencing on top of JTS, but if I
> can do it in a way that will allow for the use of other geometry
> libraries I'm open to that. I need a LinearGeometry interface for this
> even if I'm just using JTS, so I might as well try to accomodate.
>
> Byrce wrote: "W.r.t. the above: in the nomenclature of 19107, all
> geometries with 1
> topological dimension are called "curves". For clarity's sake, could you
> provide an example of a type of 1D geometry which is not a curve?"
>
> I'm afriad that I don't really understand this question. I'm not
> really a computer science guy, or even a mathematician. Just a
> surveyor. :]
>
> Bryce wrote: "Secondly, there is a separate notion of "linear
> referencing" which is
> beginning to be fleshed out. Here's a synopsis of the activity in ISO from
> http://www.isotc211.org/pow.htm. I gather you're not enthralled with the
> standard's development processes, but are open to using standards which
> currently exist. See below for which are published and which are still
> under development."
>
> This would probably interest me. I don't want to reinvent the wheel.
> In particular ISO 19148 sounds like what I want to implement.
>
> Do I need to pay for these ISO standards, or are they available
> online? Do you have to purchase them after they are no longer in draft
> form? :[
>
> Thanks for the informative post.
>
> The Sunburned Surveyor
>
>
> On 6/21
> /07, Bryce L Nordgren <[EMAIL PROTECTED]> wrote:
> >
> >
> > [EMAIL PROTECTED] wrote on 06/21/2007 04:24:44
> > PM:
> >
> > > > Also, I was hoping to abstract all linear geomtries, not just curves.
> > > > Is this type of abstraction in the module we are discussing?
> > > >
> > > I am not sure; you would need to look at the interfaces here (scroll
> > > down to the geometry section):
> > > - http://geoapi.sourceforge.net/pending/site/apidocs/index.html
> > >
> > > It *is* the raw ISO 19107 Geometry model in Java interface form.
> > >
> > > Is CompositeCurve what you are looking for?
> >
> > I've only been "sorta" following along. I have seen some of your earlier
> > messages about linear referencing. This is not the same thing as linear
> > geometries. I presume you would like to build linear referencing
> > functionality on top of the 19107 geometric objects.
> >
> > W.r.t. the above: in the nomenclature of 19107, all geometries with 1
> > topological dimension are called "curves". For clarity's sake, could you
> > provide an example of a type of 1D geometry which is not a curve?
> >
> > ISO 19107 is pretty well established, but should also be considered a
> > "basic library" upon which more complex (read: useful) things can be
> > made--exactly like what I think you have in mind. JTS, et. al, is built on
> > simple features for SQL. In ISO world, this is 19125, and is expressed as
> > a "profile" (read: stripped down version) of 19107. Most importantly, both
> > 19107 and 19125 contain plain jane geometric objects. If you want to "do"
> > stuff with them or to them, you write a "service".
> >
> > Secondly, there is a separate notion of "linear referencing" which is
> > beginning to be fleshed out. Here's a synopsis of the activity in ISO from
> > http://www.isotc211.org/pow.htm. I gather you're not enthralled with the
> > standard's development processes, but are open to using standards which
> > currently exist. See below for which are published and which are still
> > under development.
> >
> > ISO 19132 (DIS; prolly published within a year)
> > Geographic information - Location-based services - Reference model
> > The basis of all that follows.
> >
> > ISO 19133 (Published & Available)
> > Geographic information -- Location-based services -- Tracking and
> > navigation
> > "ISO 19133:2005 describes the data types, and operations associated with
> > those types, for the implementation of tracking and navigation services. It
> > is designed to specify web services that can be made available to wireless
> > devices through web-resident proxy applications, but is not restricted to
> > that environment."
> >
> > ISO 19134 (Published & Available)
> > Geographic information -- Location-based services -- Multimodal routing and
> > navigation
> > "ISO 19134:2006 specifies the data types and their associated operations
> > for the implementation of multimodal location-based services for routing
> > and navigation. It is designed to specify web services that may be made
> > available to wireless devices through web-resident proxy applications, but
> > is not limited to that environment. "
> >
> > ISO 19147 (New work item)
> > Geographic information - Location Based Services - Transfer Nodes
> > All over the world, the authorities are facing serious problems due to the
> > steady rise in the traffic volume. This rise will sooner or later call for
> > very dramatic measures, one first step might be to persuade or force car
> > users to change modes partly or entirely. In order to help this process the
> > authorities will need a complete overview of where it is possible to change
> > modes of transportation. A wide range of information or attributes is
> > needed at each node, for example the accessible modes, the scheduled
> > traffic available, the timetables, accessibility for the disabled and more
> > physical descriptions like; are there parking lots, shelters and kiosks
> > available. Also information that will help authorities manage concessionary
> > areas and pricing zones will be of great value. In addition to this; the
> > exact positioning of the node must be known; it must be possible to
> > aggregate nodes and issue unique naming and numbering of nodes. This
> > standard will be based on IS 19134 definitions of MM_TransferNode and
> > MM_Transfer. The semantic of Transfer Nodes in IS 19134 describes a change
> > of travelling mode or transfer in a multimodal network. Along with
> > MM_Transfer it enables multimodal routing. The standardised catalogue will
> > allow authorities and private transport companies to co-operate and share
> > non sensitive information between them. This will allow easier flow of data
> > and in the end it will contribute to a more efficient transport sector.
> > The proposed standard will be deeply tied to the development of ITS
> > (Intelligent Transportation Systems) solution for the public transport.
> > This proposed work should therefore be carried out in close cooperation
> > with ISO/TC 204.
> >
> > ISO 19148 (New work item)
> > Geographic information - Location Based Services - Linear Referencing
> > System
> > There is a growing demand for information that needs to be referenced
> > directly to a linear feature. This is due to the general ever increasing
> > need for location based information reflecting not only points of interest,
> > but also the longitudinal properties of the "carrier feature". There is
> > always a need to negotiate the way between points of interest. This is
> > certainly true for the transportation sector where travelling planners and
> > navigation systems have been domesticated over the last few years.
> > Apparently, it is not enough to provide services to the users of
> > the infrastructure, but also to help maintain and operate the
> > infrastructure itself. Another driver behind the need to standardize LRS's
> > is the widespread use of GIS. This calls for interoperability
> > and correspondence between different kinds of referencing systems. Thus
> > from a geometric/geographical point of view a common LRS should be derived
> > directly from the geometry of the linear feature in question. The idea of
> > the project is to develop a common model that covers the most basic needs
> > to reference all types of linear features. In order for it to be truly
> > versatile, an underlying topological structure of nodes and edges is
> > needed. The topology should be based directly on the geometry of the linear
> > feature itself. The nodes and edges will be uniquely numbered and
> > constitute a very basic geometry based referencing system. Such a model can
> > be derived from existing ISO/TC 211 standards.
> > The model must be able to meet the special challenges of the different
> > modes and domains in which it is to be used. For example within wiring it
> > must cope with the different kinds and purposes of the wires, the fan-out
> > and equipment at junctions. Within pipelines, types and purpose are
> > important in addition to the complex branching, connection valves and
> > splitter boxes. The inherently most mature domain in this respect is
> > transportation. As long as there have been roads and rails some kind of
> > LRSs have always been applied. Normally, these LRS's are based on a linear
> > measurement along the infrastructure from a known starting point usually
> > represented by physical markers along the right-of-way of the feature. Most
> > of these widely used LRS's are considered non-geometrical. Over the years,
> > though, the many challenges of roads, as how to deal with number of lanes,
> > ramps, arms and roundabouts is well understood and solved. Traditionally,
> > the need for LRS in transportation emerge from two independent sources,
> > road maintenance and operation, and the road-user aspect, Intelligent
> > Transportation Systems, ITS. In the mentioned geometrical approach, both
> > needs can be met. Thus this project calls for close cooperation between
> > ISO/TC 204 and ISO/TC 211. There has been, and is currently being done a
> > lot of work, studies and research in this field. A lot of this may be
> > regarded as stepping stones for this standard. The project will take notice
> > of this important work, for example:
> > • Refer to ISO 19133, in witch there is a package witch supplies classes
> > and types to the definition of a LRS. It is naturally to consider this
> > standard as a starting point for work.
> > ...
> > This standard will be based upon IS 19133 and wil done in close
> > co-operation with ISO/TC 204.
> >
>
*
* Project Name: Linear Referencing
* Original Organization Name: The SurveyOs Project
* Original Programmer Name: The Sunburned Surveyor
* Current Maintainer Name: The SurveyOS Project
* Current Maintainer Contact Information
* E-Mail Address: The Sunburned Surveyor
* Copyright Holder: The SurveyOS Project
* Date Last Modified: Jun 21, 2007
* Current Version Number: 00.00.01
* IDE Name: Eclipse
* IDE Version: 3.2.1
* Type: Java Class
*/
package net.surveyos.sourceforge.linearReferencing;
public interface LinearGeometry
{
/**
* Returns the length of the LinearGeometry as a double.
* Note that the length of the LinearGeometry may vary within
* the range specified by the argTolerance parameter. This is
* done to allow for the approximation of length in curved geometries.
*
* @param argTolerance The amount by which the returned length
* can vary.
* @return The length of this LinearGeometry.
*/
public abstract double getLenth(double argTolerance);
/**
* Returns the northing and easting, or Y and X ordinate values
* of the the end point of this linear geometry. The order of this
* array is not guaranteed since a LinearGeomtry is not required to
* specify direction.
*
* @return An array with 4 elements representing the ordinate value
* of the end points of this LinearGeometry. The first element is the
* northing or Y ordinate of first end point. The second element is the
easting
* or X value of the first end point. The third element is the
* northing or Y ordinate of second end point. The second element is
the easting
* or X value of the first end point.
*/
public abstract double[] getEndPointOrdinates();
/**
* Returns true if the set of ordinates represents a point that falls
on
* the LinearGeometry within the tolerance specified by the
argTolerance parameter.
*
* @param argTolerance The amount by which the point represented by the
ordinates
* can be offline and still return a value of true. This is done to
allow approximation
* in the calculation of "on line" in curved geometries.
*
* @param argOrdinates An array of two doubles representing the
ordinate values of the
* point being tested. The notrhing or Y value is the first element in
the array, the
* easting or X value is the second element in the array.
*
* @return True if the point is "on line" within the specified
tolerance.
*/
public abstract boolean isPointOnLine(double[] argPointOrdinates,
double argTolerance);
/**
* Returns an array of two doubles representing a point on the line at
the specified
* distance from one of the two end points of the LinearGeomtry.
*
* @param argDistance The distance used in the calculation of the point.
* @param argTolerance The amoung by which the distance used in the
calculation can
* vary. This is done to allow for approcimation in the calculation for
curved geometries.
*
* @param argEndPoint An array of two doubles indicating which end
point of the LinearGeometry
* should be used in this calculation.
*
* @return An array of two doubles representing the ordinate values of
the
* point "on line" at the supplied distance. The notrhing or Y value is
the first element in the array, the
* easting or X value is the second element in the array.
*/
public abstract double[] getPointOnLineAtDistance(double argDistance,
double argTolerance, int argDirectionFlag);
/**
* Returns the direction which is perpendicular to the curve at the
supplied point.
*
* @param argPointOrdinates An array of two doubles representing the
ordinate values of the
* point at which we want to calculate the perpendicular distance. The
notrhing or Y value is the first element in the array, the
* easting or X value is the second element in the array.
*
* @param argTolerance The tolerance within which the returned
direction can very. The supplied value is
* in revolutions, and should always be less than 1, since an angle of
360 degrees can be represented with a '
* revolution of 1.
*
* @return A double representing the direction in revolutions, where 1
revolution is 360 degrees. A value of
* 0 is never returned from this method. This direction will always be
represented by a value of 1.
*/
public abstract double getPerpendicularDirectionToPoitnOnLine(double[]
argPointOrdinates, double argTolerance);
}
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
