|
|
| GeoCommunity Mailing List |
| |
| Mailing List Archives |
| Subject: | Re: [gislist] SUMMARY: Linear Referencing |
| Date: |
12/21/2005 08:15:02 PM |
| From: |
Sree Rama Murthy D |
|
|
Hi,
That was very nice of Amanda to consolidate the things. Thanks for that.
Been observing people not replying all. Suggest if every body can mark
the idea/suggestion/answer to the list instead to a person.
Regards,
Sreeram.
On 12/22/05, Hargis, Amanda <ahargis@co.boulder.co.us> wrote:
>
> Thank you, everyone who emailed and phoned with ideas and thoughts about
> getting started in linear referencing. The GIS community is truly
> filled with some very generous people.
>
> Here is a summary, with my original questions first, the answers to my
> questions listed next, concluded by some additional suggestions. The
> most frequent answer to my questions was, "It depends!" We'll
> definitely be following up on your suggestions about project planning,
> further research and people to contact.
>
> Original Questions:
> 1. How do we choose route lengths? Should these be long or short? As
> an example potential route, we have a highway that traverses the county
> from north to south, passing through two incorporated cities as well as
> unincorporated county. Should each stretch be a route, or should the
> entire length be one big long route?
>
> 2. How do we choose a route ID? Should this be a randomly generated
> number, or a value that matches a key field in a transportation
> maintenance table we have?
>
> Answers about Length of Route:
> 1. It depends on the applications you will use it for.
> 2. It depends on how the existing roads are numbered - by mile
> marker? If so, where do the miles start?
> 3. Shorter is better, so that interpolation of distance will be
> more accurate.
> 4. Longer is better, with the data determining the length - e.g.,
> perhaps split the segment when the speed limit changes
> 5. Segments need to be broken at junctions with other segments for
> routing (snow plow routes, etc.)
> 6. Set up length based on "character" or "utility" rather than
> "long" or "short" - it should be an identifiable thing
> 7. Break the segments at intersections
> 8. It depends on who will use the data, and how
> 9. Longer is generally better
> 10. It depends on how the routes will be used - find a model that
> allows you to use multiple road names (e.g., Hwy. 287 is also Main
> Street)
> 11. Base the length on the usual method of identification for that
> road and break the segments where the road name / address scheme
> changes.
>
> Answers about Choice of RouteID:
> 1. It depends on the correspondence of the tables to the features.
> What if your database ID changes? Then the correspondence to the route
> will be lost.
> 2. RouteID has to match a key field in an event table
> 3. RouteID should be automatically generated by the GIS
> 4. A DBMS guideline is never to associate a record ID with any
> field in the database
> 5. It depends on what defines the routes as unique things, and how
> you use them
> 6. A randomly generated number, so performance is fastest through
> indexing
> 7. Random to enforce uniqueness
> 8. Perhaps match it to County Road ID
> 9. It depends on how the system is used. Design them to
> accommodate the road data you will encounter.
> 10. User-ids link the routes to external tables, and internal ids
> link the routes to sections, etc.
> 11. Make it a long enough number that there won't be conflicts (10 -
> 12 digits) and base it on the addressing grid / milepost system
>
> Suggestions on who to chat with:
> 1. City of Boulder
> 2. Adams County
> 3. Various consultants
> 4. Neighboring counties - coordinate!
> 5. Colorado DOT - coordinate! Use their routes / IDs?
>
> Suggestions on reading material:
>
> http://support.esri.com/index.cfm?fa=downloads.dataModels.filteredGatewa
> y&dmid=14
> http://www.dot.state.ia.us/gis/lrs_project.htm
> http://www.esri.com/news/arcuser/index.html : July-Sept. 2002
> and Oct. - Dec. 2002 issues
>
> Suggestions on Event Tables:
> 1. Make one big event table, with each record holding an Event Type
> and an Event Value (e.g., event type = Name: event value = Arapahoe)
> 2. Make lots of event tables, each with a single focus (e.g., Road
> Name events, Pavement Type events, etc.)
> 3. Make two event tables: one for static data and one for dynamic
> data, since in databases, you model each type of data differently
>
> Thanks,
> -Amanda
> .........................................
> Amanda Hargis
> GIS Coordinator, Boulder County, Colorado
> 303-441-3958 (voice) 303-441-3983 (fax)
>
|
|
Sponsored by:
For information
regarding
advertising rates
Click Here!
|
