[Taxacom] International Polychaetological Association Online

Mario H. Londoño Mesa mariolon at gmail.com
Thu May 9 09:44:46 CDT 2013


Dear colleagues,
This is just to tell that the site of the International Polychaetological
Association is online again, now at
http://www.polychaeteassoc.com<http://www.polychaete.assoc/>

It would be great if you could sign in as members, so we can have an idea
of how many we are worldwide.

The site will be kept by Andre Lobato, available at
andrefelipelobato at gmail.com. He will be glad to receive any
posts/ideas/suggestions re our research interests and to include them in
our site.
Links to useful pages to retrieve (legal) polychaetological bibliography
will be most welcome.

Warm regards to all,
Paulo Lana
______________________________**_________________
Annelida mailing list
Post: Annelida at net.bio.net
Help/archive: http://www.bio.net/biomail/**listinfo/annelida<http://www.bio.net/biomail/listinfo/annelida>
Resources: http://www.annelida.net

2013/5/9 Mario H. Londoño Mesa <mariolon at gmail.com>

>
>
> 2013/5/8 <taxacom-request at mailman.nhm.ku.edu>
>
>> Send Taxacom mailing list submissions to
>>         taxacom at mailman.nhm.ku.edu
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         http://mailman.nhm.ku.edu/mailman/listinfo/taxacom
>> or, via email, send a message with subject or body 'help' to
>>         taxacom-request at mailman.nhm.ku.edu
>>
>> You can reach the person managing the list at
>>         taxacom-owner at mailman.nhm.ku.edu
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Taxacom digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Re: Data quality of aggregated datasets (Richard Pyle)
>>    2. Re: Data quality of aggregated datasets (Richard Pyle)
>>    3. Re: Data quality of aggregated datasets (Richard Pyle)
>>    4. Re: Data quality of aggregated datasets (Doug Yanega)
>>    5. Re: Data quality of aggregated datasets (Mary Barkworth)
>>    6. Re: Data quality of aggregated datasets (Dave Vieglais)
>>    7. Re: Data quality of aggregated datasets (Dean Pentcheff)
>>    8. Asking a paper (Vin?cius Antonio de Oliveira Dittrich)
>>    9. Re: Data quality of aggregated datasets (Doug Yanega)
>>   10. Re: Data quality of aggregated datasets (Richard Pyle)
>>   11. Paper Request Lazarides 1997 (Sami Rabei)
>>   12. Re: Data quality of aggregated datasets (Tom Schweich)
>>   13. Accuracy of GPS Receivers, was: Re:  Data quality of
>>       aggregated datasets (Tom Schweich)
>>   14. Re: Data quality of aggregated datasets (Dave Vieglais)
>>   15. Re: Data quality of aggregated datasets (Fred Schueler)
>>   16. Re: Accuracy of GPS Receivers, was... (Robert Mesibov)
>>   17. Re: Accuracy of GPS Receivers, was... (Poly, William)
>>   18. Re: Accuracy of GPS Receivers, was... (Piero Delprete)
>>   19. Plant nomenclatural issues (Peter Rooney)
>>   20. Re: Paper Request Lazarides 1997 (Sami Rabei)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Tue, 7 May 2013 07:03:45 -1000
>> From: "Richard Pyle" <deepreef at bishopmuseum.org>
>> Subject: Re: [Taxacom] Data quality of aggregated datasets
>> To: "'Quentin Groom'" <quentin.groom at br.fgov.be>
>> Cc: 'Robert Mesibov' <mesibov at southcom.com.au>, 'TAXACOM'
>>         <taxacom at mailman.nhm.ku.edu>
>> Message-ID: <006901ce4b44$d6b74f40$8425edc0$@bishopmuseum.org>
>> Content-Type: text/plain;       charset="us-ascii"
>>
>> > I take your point about the description of accuracy and precision
>> however,
>> for all practical purposes occupancy within a grid is much more useful.
>>
>> That's debatable.  It depends on what you want to do with the data.
>>
>> Also, you can easily convert point+radius values into a defined grid
>> (which
>> includes rejecting datapoints whose circle footprint spans more than one
>> grid cell -- or defining rules about whether or not an occurrence is known
>> with enough accuracy to be included in a particular grid analaysis).  But
>> if
>> you store your data in the form of occurrence within a particular grid
>> cell,
>> you can't convert the other direction.  Grid-cell structures may be great
>> for certain kinds of data analysis, but not so great for capturing/storing
>> the data.  I'm not sure whether your point in your previous post was that
>> data should be captured/stored that way (gred-cell), or simply presented
>> to
>> end-users that way.
>>
>> Personally, I'd rather have the data presented to me as point+radius, then
>> I'll make my own rules about how to reject points from the analysis and
>> what
>> cell to score each point in (if I want to do a cell analysis).  So, in
>> either case, while you have a good point for how people use and transform
>> these data to perform certain kinds of analysis, I'm not sure it has
>> bearing
>> on how data should be captured/stored/presented to end users.
>>
>> > The conversion of squares to circles and circles back to squares could
>> be
>> the
>> > origin of many of the discrepancies between original data and GBIF and
>> will
>> > lead to the rejection of potentially useful data when the circle borders
>> > overlap with those of the square.
>>
>> Yes -- which is why you don't want to convert the data back and forth.
>>  But
>> you have to store it somehow, and as I said above, it's better to start
>> with
>> the point-radius that is captured/stored as accurately as the original
>> data
>> allow for, then convert to a grid (=bounding box) if/when the analysis
>> calls
>> for it; than it is to start with an arbitrary grid (i.e., as opposed to a
>> bounding box whose shape/borders are optimized to represent the smallest
>> footprint within which the occurrence is likely to have happened).  In
>> other
>> words, the error is not symmetrical when doing the conversion.  Converting
>> from point-radius (or even from custom bounding box) to arbitrary grid
>> involves less data loss than the other way around.
>>
>> > I'd like to see anyone uses those radii for anything else except for
>> determining
>> > if a record belongs within a grid square. Why shouldn't taxonomists
>> collect
>> > gridded data in the first place, just as ecologist have been for years?
>>
>> I use the radius to reject points with insufficient accuracy.  When data
>> have been converted to a grid, you lose that information.  For example, if
>> you capture the data for a particular grid, you cannot later analyze the
>> data based on a different grid pattern.  If your data are in point+radius
>> format, you can very easily determine which points are appropriate for use
>> within a grid of different scale or offset.
>>
>> Aloha,
>> Rich
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Tue, 7 May 2013 07:14:52 -1000
>> From: "Richard Pyle" <deepreef at bishopmuseum.org>
>> Subject: Re: [Taxacom] Data quality of aggregated datasets
>> To: "'Robert Mesibov'" <mesibov at southcom.com.au>,       "'Quentin Groom'"
>>         <quentin.groom at br.fgov.be>
>> Cc: 'TAXACOM' <taxacom at mailman.nhm.ku.edu>
>> Message-ID: <006a01ce4b46$63dd1430$2b973c90$@bishopmuseum.org>
>> Content-Type: text/plain;       charset="us-ascii"
>>
>> One thing I might not have made clear in my previous post:  storing
>> locality
>> data in the form of a custom bounding box (e.g., where you record two
>> lat/lon coordinates, and use them as two opposite corners of a rectangle)
>> is
>> essentially the same as point-radius, so this isn't an issue of circles
>> vs.
>> squares.  The point is that when you capture or interpret data based on a
>> pre-defined grid (UTM, or some other grid), you lose more information than
>> you need to.  Regardless of whether I had a GPS when I captured a
>> specimen,
>> or whether I'm trying to georeference a specimen label that says the
>> specimen was taken "Along a trail 0.25 mile SE of the big tree at the end
>> of
>> Mulligan's Road", it's better to capture and store the data with as much
>> accuracy as you can, then filter/convert it as appropriate into an
>> arbitrary
>> grid as needed for analysis.
>>
>> Aloha,
>> Rich
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Tue, 7 May 2013 07:20:41 -1000
>> From: "Richard Pyle" <deepreef at bishopmuseum.org>
>> Subject: Re: [Taxacom] Data quality of aggregated datasets
>> To: "'Quentin Groom'" <quentin.groom at br.fgov.be>,       "'Robert
>> Mesibov'"
>>         <mesibov at southcom.com.au>
>> Cc: 'TAXACOM' <taxacom at mailman.nhm.ku.edu>
>> Message-ID: <006b01ce4b47$34bd1050$9e3730f0$@bishopmuseum.org>
>> Content-Type: text/plain;       charset="iso-8859-1"
>>
>> > There is nothing wrong with collecting fine scale records on a GPS using
>> longitudes and latitudes, but when you are using a GPS there
>> > is no need for a radius as the error is well within the walking distance
>> of most creatures.?
>>
>> You should *always* capture the radius -- even for GPS coordinates.  You
>> cannot know in advance what the information will be useful for, and not
>> all
>> GPS devices record with the same accuracy.  A GPS with +/- 100m may be no
>> different from one with +/- 10m if you are doing ecological analysis; but
>> it
>> could make a huge difference if your goal is to return to the same tree or
>> coral head or whatever.  I think it's just silly to throw away information
>> when it's easy to capture.  It's also silly to think you know in advance
>> what information will, or will not, be useful to future researchers.
>>
>> Aloha,
>> Rich
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Tue, 07 May 2013 11:37:41 -0700
>> From: Doug Yanega <dyanega at ucr.edu>
>> Subject: Re: [Taxacom] Data quality of aggregated datasets
>> To: "taxacom at mailman.nhm.ku.edu" <taxacom at mailman.nhm.ku.edu>
>> Message-ID: <518949F5.4080105 at ucr.edu>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> On 5/7/13 5:15 AM, Mary Barkworth wrote:
>> > The basic reason that the data will always be "raw" is that we have no
>> reliable means of communicating with the dead. When a label says Logan,
>> Utah, I am told to use the city's current boundaries. Technically, I could
>> look up its boundaries at the time the specimen was collected but perhaps
>> all the collector was doing was naming the nearest settlement that he or
>> she knew of, or the postal district, or home based for that day or week.
>> Moreover no one is willing to pay the herbarium for the additional work
>> required to check into alternative estimates. Actually, they are not
>> willing to pay for anything; we (like all collections) provide the data for
>> free. When it comes to collection data, we can adhere to standard protocols
>> but all that provides are estimates calculated in standard way. Whether
>> that is good enough depends on the question being addressed and the
>> organism(s) involved. Data users should always evaluate the data they wish
>> to use - and be grateful for the quantity being made available (gratitude
>> can be expressed by informing the head of the collection of any errors that
>> need fixing, mention in the acknowledgements, and an email to the head of
>> the collection who may not otherwise know that its records have been used).
>> >
>> This is an example of how different standards and protocols make a
>> difference. In our database, we accept the USGS GNIS georef placement of
>> Logan, Utah as 41 44 08 N, 111 50 04 W. However, we use an error radius
>> of 10 km around that point. This is an *arbitrary* error radius used to
>> account for the very real potential that someone whose label simply said
>> "Logan" could have been outside of the boundary of the city proper
>> (which, incidentally, has a radius of around 8 km, if one uses a
>> satellite image to determine the extent of the densely populated zone).
>> The decision to use a 10 km radius is part of our in-house standard
>> protocol for contending with "populated place" category names, which
>> uses several criteria, virtually all of which include the process
>> "...and then round UP". This does not require any investment of time or
>> energy to look for alternative estimates; we simply opt to play things
>> conservatively, and use the largest minimum error radius (even though
>> that sounds like an oxymoron), to avoid false precision while giving
>> *realistic* accuracy. To further clarify, if (hypothetically) the next
>> nearest city was only 10 km from Logan, then the largest minimum error
>> radius for "Logan" would extend to roughly halfway between the two
>> cities (5 km), because the protocol assumes that a person collecting in
>> between two towns will make labels referring to the nearest one, if they
>> do not otherwise specify displacement.
>>
>> A few rules of thumb like these can serve to make georeferencing easier
>> and more practical than the rather elaborate set of "best practices"
>> that Dean Pentcheff linked here; those "best practices" are spectacular
>> IF you can afford the time and energy and IF you are really, really
>> focused on precision and objectivity rather than accuracy (especially if
>> you want a computer to do your work for you). This is linked to the
>> desire of the authors of that set of guidelines to automate the process
>> of georeferencing, while developing the Biogeomancer georeferencing
>> tool. But guidelines that are intended to work for automation do not
>> necessary correspond to protocols that are intended for a human being
>> using, say, Google Earth. A pertinent example is the label in our
>> collection that reads "campground 4 mi E Logan". Biogeomancer uses the
>> GNIS point I mentioned above as the origin and then measures exactly 4
>> miles from that, and draws a rather large error radius around the
>> resulting point (based on the theoretical possibility that the angle of
>> displacement could have been anything between NE and SE). Very
>> objective, and very precise - and utterly wrong; the campground in
>> question is not within this circle, because most of that circle is
>> inside the city limits of Logan, which is more than 4 miles in radius. A
>> human-powered protocol would start measuring from the eastern edge of
>> the city, rather than its center, and measure actual distances along
>> roads, rather than fixed compass directions in straight lines. A human
>> using Google Earth can see that there is indeed a campground along the
>> highway almost exactly four miles east of the mouth of Logan Canyon,
>> which abuts the eastern edge of the city, and one can plot that point
>> with a very small error radius (basically, the limits of the campground
>> itself) - which is in fact both more accurate AND more precise than the
>> "objective" protocol. The reason I bother to go through this example in
>> such detail is the end result: a data provider using an automated georef
>> tool will give a point that is 5 miles away from the actual collecting
>> site, AND in a completely different habitat. That is an extremely
>> significant error, resulting solely from the reliance on automation -
>> two data providers starting with original data of the exact same quality
>> (a label reading "campground 4 mi E Logan") and following different
>> "standard protocols" will produce data sets of completely *different*
>> quality. I doubt that data aggregators or users are paying any attention
>> to WHAT the georeferencing protocols are behind the datasets they are
>> using.
>>
>> Sincerely,
>>
>> --
>> Doug Yanega      Dept. of Entomology       Entomology Research Museum
>> Univ. of California, Riverside, CA 92521-0314     skype: dyanega
>> phone: (951) 827-4315 (disclaimer: opinions are mine, not UCR's)
>>               http://cache.ucr.edu/~heraty/yanega.html
>>    "There are some enterprises in which a careful disorderliness
>>          is the true method" - Herman Melville, Moby Dick, Chap. 82
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Tue, 7 May 2013 18:58:29 +0000
>> From: Mary Barkworth <Mary.Barkworth at usu.edu>
>> Subject: Re: [Taxacom] Data quality of aggregated datasets
>> To: "TAXACOM (taxacom at mailman.nhm.ku.edu)"
>>         <taxacom at mailman.nhm.ku.edu>
>> Message-ID:
>>         <E5C2D70F8AC66C4AAAA6AEC0EB7201B49066D600 at mb02.aggies.usu.edu>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> I agree - and we often have a comment in our georeferencing field that we
>> have modified the data provided by Geolocate.
>>
>>
>> -----Original Message-----
>> From: taxacom-bounces at mailman.nhm.ku.edu [mailto:
>> taxacom-bounces at mailman.nhm.ku.edu] On Behalf Of Doug Yanega
>> Sent: Tuesday, May 7, 2013 12:38 PM
>> To: taxacom at mailman.nhm.ku.edu
>> Subject: Re: [Taxacom] Data quality of aggregated datasets
>>
>> On 5/7/13 5:15 AM, Mary Barkworth wrote:
>> > The basic reason that the data will always be "raw" is that we have no
>> reliable means of communicating with the dead. When a label says Logan,
>> Utah, I am told to use the city's current boundaries. Technically, I could
>> look up its boundaries at the time the specimen was collected but perhaps
>> all the collector was doing was naming the nearest settlement that he or
>> she knew of, or the postal district, or home based for that day or week.
>> Moreover no one is willing to pay the herbarium for the additional work
>> required to check into alternative estimates. Actually, they are not
>> willing to pay for anything; we (like all collections) provide the data for
>> free. When it comes to collection data, we can adhere to standard protocols
>> but all that provides are estimates calculated in standard way. Whether
>> that is good enough depends on the question being addressed and the
>> organism(s) involved. Data users should always evaluate the data they wish
>> to use - and be grateful for the quantity being made available (gratitude
>> can be expressed by informing the head of the collection of any errors that
>> need fixing, mention in the acknowledgements, and an email to the head of
>> the collection who may not otherwise know that its records have been used).
>> >
>> This is an example of how different standards and protocols make a
>> difference. In our database, we accept the USGS GNIS georef placement of
>> Logan, Utah as 41 44 08 N, 111 50 04 W. However, we use an error radius of
>> 10 km around that point. This is an *arbitrary* error radius used to
>> account for the very real potential that someone whose label simply said
>> "Logan" could have been outside of the boundary of the city proper (which,
>> incidentally, has a radius of around 8 km, if one uses a satellite image to
>> determine the extent of the densely populated zone).
>> The decision to use a 10 km radius is part of our in-house standard
>> protocol for contending with "populated place" category names, which uses
>> several criteria, virtually all of which include the process "...and then
>> round UP". This does not require any investment of time or energy to look
>> for alternative estimates; we simply opt to play things conservatively, and
>> use the largest minimum error radius (even though that sounds like an
>> oxymoron), to avoid false precision while giving
>> *realistic* accuracy. To further clarify, if (hypothetically) the next
>> nearest city was only 10 km from Logan, then the largest minimum error
>> radius for "Logan" would extend to roughly halfway between the two cities
>> (5 km), because the protocol assumes that a person collecting in between
>> two towns will make labels referring to the nearest one, if they do not
>> otherwise specify displacement.
>>
>> A few rules of thumb like these can serve to make georeferencing easier
>> and more practical than the rather elaborate set of "best practices"
>> that Dean Pentcheff linked here; those "best practices" are spectacular
>> IF you can afford the time and energy and IF you are really, really focused
>> on precision and objectivity rather than accuracy (especially if you want a
>> computer to do your work for you). This is linked to the desire of the
>> authors of that set of guidelines to automate the process of
>> georeferencing, while developing the Biogeomancer georeferencing tool. But
>> guidelines that are intended to work for automation do not necessary
>> correspond to protocols that are intended for a human being using, say,
>> Google Earth. A pertinent example is the label in our collection that reads
>> "campground 4 mi E Logan". Biogeomancer uses the GNIS point I mentioned
>> above as the origin and then measures exactly 4 miles from that, and draws
>> a rather large error radius around the resulting point (based on the
>> theoretical possibility that the angle of displacement could have been
>> anything between NE and SE). Very objective, and very precise - and utterly
>> wrong; the campground in question is not within this circle, because most
>> of that circle is inside the city limits of Logan, which is more than 4
>> miles in radius. A human-powered protocol would start measuring from the
>> eastern edge of the city, rather than its center, and measure actual
>> distances along roads, rather than fixed compass directions in straight
>> lines. A human using Google Earth can see that there is indeed a campground
>> along the highway almost exactly four miles east of the mouth of Logan
>> Canyon, which abuts the eastern edge of the city, and one can plot that
>> point with a very small error radius (basically, the limits of the
>> campground
>> itself) - which is in fact both more accurate AND more precise than the
>> "objective" protocol. The reason I bother to go through this example in
>> such detail is the end result: a data provider using an automated georef
>> tool will give a point that is 5 miles away from the actual collecting
>> site, AND in a completely different habitat. That is an extremely
>> significant error, resulting solely from the reliance on automation - two
>> data providers starting with original data of the exact same quality (a
>> label reading "campground 4 mi E Logan") and following different "standard
>> protocols" will produce data sets of completely *different* quality. I
>> doubt that data aggregators or users are paying any attention to WHAT the
>> georeferencing protocols are behind the datasets they are using.
>>
>> Sincerely,
>>
>> --
>> Doug Yanega      Dept. of Entomology       Entomology Research Museum
>> Univ. of California, Riverside, CA 92521-0314     skype: dyanega
>> phone: (951) 827-4315 (disclaimer: opinions are mine, not UCR's)
>>               http://cache.ucr.edu/~heraty/yanega.html
>>    "There are some enterprises in which a careful disorderliness
>>          is the true method" - Herman Melville, Moby Dick, Chap. 82
>>
>>
>>
>> _______________________________________________
>> Taxacom Mailing List
>> Taxacom at mailman.nhm.ku.edu
>> http://mailman.nhm.ku.edu/mailman/listinfo/taxacom
>>
>> The Taxacom Archive back to 1992 may be searched with either of these
>> methods:
>>
>> (1) by visiting http://taxacom.markmail.org
>>
>> (2) a Google search specified as:  site:
>> mailman.nhm.ku.edu/pipermail/taxacom  your search terms here
>>
>> Celebrating 26 years of Taxacom in 2013.
>>
>>
>>
>> ------------------------------
>>
>> Message: 6
>> Date: Tue, 7 May 2013 15:04:35 -0400
>> From: Dave Vieglais <vieglais at ku.edu>
>> Subject: Re: [Taxacom] Data quality of aggregated datasets
>> To: Richard Pyle <deepreef at bishopmuseum.org>
>> Cc: TAXACOM <taxacom at mailman.nhm.ku.edu>
>> Message-ID: <10CFD448-A380-4018-9C67-C78A1ED28B63 at ku.edu>
>> Content-Type: text/plain; charset=iso-8859-1
>>
>> In addition, the confidence associated with the error estimate should
>> also be recorded. For example, does "+/- 100m" refer to the 95% confidence
>> interval? Circular Error Probable (50%)? 3 sigma ellipse (98.9%)? etc.
>>
>> On 2013.05.07, at 13:20-0400, Richard Pyle <deepreef at bishopmuseum.org>
>> wrote:
>>
>> >> There is nothing wrong with collecting fine scale records on a GPS
>> using
>> > longitudes and latitudes, but when you are using a GPS there
>> >> is no need for a radius as the error is well within the walking
>> distance
>> > of most creatures.
>> >
>> > You should *always* capture the radius -- even for GPS coordinates.  You
>> > cannot know in advance what the information will be useful for, and not
>> all
>> > GPS devices record with the same accuracy.  A GPS with +/- 100m may be
>> no
>> > different from one with +/- 10m if you are doing ecological analysis;
>> but it
>> > could make a huge difference if your goal is to return to the same tree
>> or
>> > coral head or whatever.  I think it's just silly to throw away
>> information
>> > when it's easy to capture.  It's also silly to think you know in advance
>> > what information will, or will not, be useful to future researchers.
>> >
>> > Aloha,
>> > Rich
>> >
>> >
>> > _______________________________________________
>> > Taxacom Mailing List
>> > Taxacom at mailman.nhm.ku.edu
>> > http://mailman.nhm.ku.edu/mailman/listinfo/taxacom
>> >
>> > The Taxacom Archive back to 1992 may be searched with either of these
>> methods:
>> >
>> > (1) by visiting http://taxacom.markmail.org
>> >
>> > (2) a Google search specified as:  site:
>> mailman.nhm.ku.edu/pipermail/taxacom  your search terms here
>> >
>> > Celebrating 26 years of Taxacom in 2013.
>> >
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 7
>> Date: Tue, 7 May 2013 12:35:09 -0700
>> From: Dean Pentcheff <pentcheff at gmail.com>
>> Subject: Re: [Taxacom] Data quality of aggregated datasets
>> To: "taxacom at mailman.nhm.ku.edu" <taxacom at mailman.nhm.ku.edu>
>> Message-ID:
>>         <CAKMaq6E6hMN30vdD+uCPOPoYiPJfoCJcDTa-b5x=
>> kgJJ6qYowg at mail.gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>>
>> I agree. I see those "elaborate best practices" (as encoded by Chapman &
>> Wieczorek in the Geomancer document) as a codification of
>> well-throught-through rules of thumb that can be applied in the absence of
>> other information. The key (in my mind) is that the "objective, and very
>> precise" estimates always yield to additional information.
>>
>> In your example, the critical piece of additional information is
>> "campground". If the hypothetical label was just "4 mi E Logan", I don't
>> think you could do much better than the automatic estimated location. But
>> "campground 4 mi E Logan" lets you (yes you, an expert :) snuffle around
>> for that feature, find it, assess whether it's likely to be the campground
>> in question (how many other campgrounds are in that area?), and if it
>> seems
>> reasonable, assign that as the high-probability collection location.
>>
>> -Dean
>> --
>> Dean Pentcheff
>> pentcheff at gmail.com
>> dpentche at nhm.org
>>
>>
>> On Tue, May 7, 2013 at 11:37 AM, Doug Yanega <dyanega at ucr.edu> wrote:
>>
>> > On 5/7/13 5:15 AM, Mary Barkworth wrote:
>> > > The basic reason that the data will always be "raw" is that we have no
>> > reliable means of communicating with the dead. When a label says Logan,
>> > Utah, I am told to use the city's current boundaries. Technically, I
>> could
>> > look up its boundaries at the time the specimen was collected but
>> perhaps
>> > all the collector was doing was naming the nearest settlement that he or
>> > she knew of, or the postal district, or home based for that day or week.
>> > Moreover no one is willing to pay the herbarium for the additional work
>> > required to check into alternative estimates. Actually, they are not
>> > willing to pay for anything; we (like all collections) provide the data
>> for
>> > free. When it comes to collection data, we can adhere to standard
>> protocols
>> > but all that provides are estimates calculated in standard way. Whether
>> > that is good enough depends on the question being addressed and the
>> > organism(s) involved. Data users should always evaluate the data they
>> wish
>> > to use - and be grateful for the quantity being made available
>> (gratitude
>> > can be expressed by informing the head of the collection of any errors
>> that
>> > need fixing, mention in the acknowledgements, and an email to the head
>> of
>> > the collection who may not otherwise know that its records have been
>> used).
>> > >
>> > This is an example of how different standards and protocols make a
>> > difference. In our database, we accept the USGS GNIS georef placement of
>> > Logan, Utah as 41 44 08 N, 111 50 04 W. However, we use an error radius
>> > of 10 km around that point. This is an *arbitrary* error radius used to
>> > account for the very real potential that someone whose label simply said
>> > "Logan" could have been outside of the boundary of the city proper
>> > (which, incidentally, has a radius of around 8 km, if one uses a
>> > satellite image to determine the extent of the densely populated zone).
>> > The decision to use a 10 km radius is part of our in-house standard
>> > protocol for contending with "populated place" category names, which
>> > uses several criteria, virtually all of which include the process
>> > "...and then round UP". This does not require any investment of time or
>> > energy to look for alternative estimates; we simply opt to play things
>> > conservatively, and use the largest minimum error radius (even though
>> > that sounds like an oxymoron), to avoid false precision while giving
>> > *realistic* accuracy. To further clarify, if (hypothetically) the next
>> > nearest city was only 10 km from Logan, then the largest minimum error
>> > radius for "Logan" would extend to roughly halfway between the two
>> > cities (5 km), because the protocol assumes that a person collecting in
>> > between two towns will make labels referring to the nearest one, if they
>> > do not otherwise specify displacement.
>> >
>> > A few rules of thumb like these can serve to make georeferencing easier
>> > and more practical than the rather elaborate set of "best practices"
>> > that Dean Pentcheff linked here; those "best practices" are spectacular
>> > IF you can afford the time and energy and IF you are really, really
>> > focused on precision and objectivity rather than accuracy (especially if
>> > you want a computer to do your work for you). This is linked to the
>> > desire of the authors of that set of guidelines to automate the process
>> > of georeferencing, while developing the Biogeomancer georeferencing
>> > tool. But guidelines that are intended to work for automation do not
>> > necessary correspond to protocols that are intended for a human being
>> > using, say, Google Earth. A pertinent example is the label in our
>> > collection that reads "campground 4 mi E Logan". Biogeomancer uses the
>> > GNIS point I mentioned above as the origin and then measures exactly 4
>> > miles from that, and draws a rather large error radius around the
>> > resulting point (based on the theoretical possibility that the angle of
>> > displacement could have been anything between NE and SE). Very
>> > objective, and very precise - and utterly wrong; the campground in
>> > question is not within this circle, because most of that circle is
>> > inside the city limits of Logan, which is more than 4 miles in radius. A
>> > human-powered protocol would start measuring from the eastern edge of
>> > the city, rather than its center, and measure actual distances along
>> > roads, rather than fixed compass directions in straight lines. A human
>> > using Google Earth can see that there is indeed a campground along the
>> > highway almost exactly four miles east of the mouth of Logan Canyon,
>> > which abuts the eastern edge of the city, and one can plot that point
>> > with a very small error radius (basically, the limits of the campground
>> > itself) - which is in fact both more accurate AND more precise than the
>> > "objective" protocol. The reason I bother to go through this example in
>> > such detail is the end result: a data provider using an automated georef
>> > tool will give a point that is 5 miles away from the actual collecting
>> > site, AND in a completely different habitat. That is an extremely
>> > significant error, resulting solely from the reliance on automation -
>> > two data providers starting with original data of the exact same quality
>> > (a label reading "campground 4 mi E Logan") and following different
>> > "standard protocols" will produce data sets of completely *different*
>> > quality. I doubt that data aggregators or users are paying any attention
>> > to WHAT the georeferencing protocols are behind the datasets they are
>> > using.
>> >
>> > Sincerely,
>> >
>> > --
>> > Doug Yanega      Dept. of Entomology       Entomology Research Museum
>> > Univ. of California, Riverside, CA 92521-0314     skype: dyanega
>> > phone: (951) 827-4315 (disclaimer: opinions are mine, not UCR's)
>> >               http://cache.ucr.edu/~heraty/yanega.html
>> >    "There are some enterprises in which a careful disorderliness
>> >          is the true method" - Herman Melville, Moby Dick, Chap. 82
>> >
>> >
>> >
>> > _______________________________________________
>> > Taxacom Mailing List
>> > Taxacom at mailman.nhm.ku.edu
>> > http://mailman.nhm.ku.edu/mailman/listinfo/taxacom
>> >
>> > The Taxacom Archive back to 1992 may be searched with either of these
>> > methods:
>> >
>> > (1) by visiting http://taxacom.markmail.org
>> >
>> > (2) a Google search specified as:  site:
>> > mailman.nhm.ku.edu/pipermail/taxacom  your search terms here
>> >
>> > Celebrating 26 years of Taxacom in 2013.
>> >
>>
>>
>> ------------------------------
>>
>> Message: 8
>> Date: Tue, 7 May 2013 16:35:30 -0300
>> From: Vin?cius Antonio de Oliveira Dittrich     <vinarc at gmail.com>
>> Subject: [Taxacom] Asking a paper
>> To: Taxacom <taxacom at mailman.nhm.ku.edu>
>> Message-ID:
>>         <CAOCUs=
>> VqgNBG9zRm-dLSNvPH41vsUCiCSapE3ispKP3C1MCQ7A at mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>>    Dear all: by any chance does anybody have the following paper in .pdf
>> format?
>>
>>    LEANDRI, J. 1963.  Un botaniste fran?ais pionnier de la floristique
>> br?silienne. Adansonia 3: 5-18.
>>
>>    Best wishes to all,
>>
>>    Vin?cius
>>
>> --
>> Prof. Dr. Vin?cius Antonio de Oliveira Dittrich
>> Curador de fungos e pterid?fitas do Herb?rio CESJ
>> Instituto de Ci?ncias Biol?gicas, Universidade Federal de Juiz de Fora
>> Rua Jos? Louren?o Kelmer, s/n - Campus Universit?rio, Bairro S?o Pedro
>> Juiz de Fora, MG, Brasil - CEP 36036-900
>> Work: 55 (32) 2102-3224
>> Panoramio <http://www.panoramio.com/user/vina>
>> Pterid?fitas - diversidade e conserva??o<
>> http://www.icb.ufmg.br/pteridofitas/>
>> Herb?rio CESJ <http://www.ufjf.br/herbario/>
>> Academia.edu <http://ufjf-br.academia.edu/Vin%C3%ADciusDittrich>
>> Skype: vinacrt
>>
>>
>> ------------------------------
>>
>> Message: 9
>> Date: Tue, 07 May 2013 13:21:17 -0700
>> From: Doug Yanega <dyanega at ucr.edu>
>> Subject: Re: [Taxacom] Data quality of aggregated datasets
>> To: "taxacom at mailman.nhm.ku.edu" <taxacom at mailman.nhm.ku.edu>
>> Message-ID: <5189623D.4020905 at ucr.edu>
>> Content-Type: text/plain; charset=UTF-8; format=flowed
>>
>> On 5/7/13 12:04 PM, Dave Vieglais wrote:
>> > In addition, the confidence associated with the error estimate should
>> also be recorded. For example, does "+/- 100m" refer to the 95% confidence
>> interval? Circular Error Probable (50%)? 3 sigma ellipse (98.9%)? etc.
>> >
>> This sounds like what I mean by false precision. If your error radius is
>> "The ballpark estimate for the wandering radius of this particular
>> entomologist after he parked his car" then there is NO utility in trying
>> to assign confidence limits and probability values to that radius. If
>> you just say "We arbitrarily draw a 2 km radius in order to accommodate
>> for all reasonable sources of error LESS than 2 km in extent", then,
>> likewise, no further parameters are necessary or appropriate. Even for
>> georeferences that I personally recorded using a GPS, I will at least
>> double the actual distance I walked from that point when providing an
>> error radius, rounded to the nearest multiple of 100 meters, just so it
>> is NOT necessary to specify anything more detailed - because it is
>> vastly simpler to just use a large enough error value to SUBSUME any of
>> the error values one could painstakingly calculate or quantify using
>> other means. Why would anyone bother trying to calculate a confidence
>> interval for a label that says only "6.35 miles S of Chicago, IL", or
>> "Delhi, India"? Worrying about false precision just wastes time, since
>> it doesn't increase the value of one's data; that is, in effect, the
>> criterion that distinguishes *false* precision. More numbers, or more
>> decimal places, is valuable *only up to a point*. What is important, as
>> Rich Pyle notes, is ACCURACY.
>>
>> On 5/7/13 12:35 PM, Dean Pentcheff wrote:
>> > I agree. I see those "elaborate best practices" (as encoded by Chapman
>> > & Wieczorek in the Geomancer document) as a codification of
>> > well-throught-through rules of thumb that can be applied in the
>> > absence of other information. The key (in my mind) is that the
>> > "objective, and very precise" estimates always yield to additional
>> > information.
>> >
>> > In your example, the critical piece of additional information is
>> > "campground". If the hypothetical label was just "4 mi E Logan", I
>> > don't think you could do much better than the automatic estimated
>> > location. But "campground 4 mi E Logan" lets you (yes you, an expert
>> > :) snuffle around for that feature, find it, assess whether it's
>> > likely to be the campground in question (how many other campgrounds
>> > are in that area?), and if it seems reasonable, assign that as the
>> > high-probability collection location.
>> >
>> Actually, a human would still do much better than Biogeomancer if the
>> label was just "4 mi E Logan", because it would start from the center of
>> the city, where a human would start from the edge AND measure along a
>> road. The bigger the city, and the more roads deviate from perfectly
>> straight, and along cardinal compass headings, the worse an automated
>> system will perform. One does not have to be an expert, one simply has
>> to realize that (1) human beings driving cars measure distances from
>> boundaries and landmarks, using their odometers, (2) roads can curve,
>> and (3) roads can go at angles other than increments of 45 degrees
>> relative to a starting point. Show me an automated georeferencing tool
>> that incorporates all three of those realities and I'll be the first
>> person to hail that tool as the answer to our prayers. For the time
>> being, I simply don't accept that you can get high-quality georef data
>> except by human analysis. Remember, empirical results indicate only
>> about a 40% match between the two protocols, and only 60% of records
>> overlap within a reasonable error radius.
>>
>> Sincerely,
>>
>> --
>> Doug Yanega      Dept. of Entomology       Entomology Research Museum
>> Univ. of California, Riverside, CA 92521-0314     skype: dyanega
>> phone: (951) 827-4315 (disclaimer: opinions are mine, not UCR's)
>>               http://cache.ucr.edu/~heraty/yanega.html
>>    "There are some enterprises in which a careful disorderliness
>>          is the true method" - Herman Melville, Moby Dick, Chap. 82
>>
>>
>>
>> ------------------------------
>>
>> Message: 10
>> Date: Tue, 7 May 2013 10:57:33 -1000
>> From: "Richard Pyle" <deepreef at bishopmuseum.org>
>> Subject: Re: [Taxacom] Data quality of aggregated datasets
>> To: "'Dave Vieglais'" <vieglais at ku.edu>
>> Cc: 'TAXACOM' <taxacom at mailman.nhm.ku.edu>
>> Message-ID: <009701ce4b65$7f8c14f0$7ea43ed0$@bishopmuseum.org>
>> Content-Type: text/plain;       charset="us-ascii"
>>
>> Hi Dave,
>>
>> My use of "+/-" was in reference to the accuracy of the GPS device.  I'm
>> not
>> sure how such devices estimate the error radius, and I'm not sure how the
>> average field biologist would find out.  However, many GPS devices I've
>> used
>> give me a simple number representing "Accuracy", expressed as a distance
>> (usually in feet or meters).  That's a number I can easily capture as a
>> radius.  How the GPS device generated that number, and what the basis of
>> the
>> error estimate used by the GPS device is, may be a bit more cryptic.
>>
>> Aloha,
>> Rich
>>
>>
>> > -----Original Message-----
>> > From: Dave Vieglais [mailto:dave.vieglais at gmail.com] On Behalf Of Dave
>> > Vieglais
>> > Sent: Tuesday, May 07, 2013 9:05 AM
>> > To: Richard Pyle
>> > Cc: TAXACOM
>> > Subject: Re: [Taxacom] Data quality of aggregated datasets
>> >
>> > In addition, the confidence associated with the error estimate should
>> also
>> be
>> > recorded. For example, does "+/- 100m" refer to the 95% confidence
>> > interval? Circular Error Probable (50%)? 3 sigma ellipse (98.9%)? etc.
>> >
>> > On 2013.05.07, at 13:20-0400, Richard Pyle <deepreef at bishopmuseum.org>
>> > wrote:
>> >
>> > >> There is nothing wrong with collecting fine scale records on a GPS
>> > >> using
>> > > longitudes and latitudes, but when you are using a GPS there
>> > >> is no need for a radius as the error is well within the walking
>> > >> distance
>> > > of most creatures.
>> > >
>> > > You should *always* capture the radius -- even for GPS coordinates.
>> > > You cannot know in advance what the information will be useful for,
>> > > and not all GPS devices record with the same accuracy.  A GPS with +/-
>> > > 100m may be no different from one with +/- 10m if you are doing
>> > > ecological analysis; but it could make a huge difference if your goal
>> > > is to return to the same tree or coral head or whatever.  I think it's
>> > > just silly to throw away information when it's easy to capture.  It's
>> > > also silly to think you know in advance what information will, or will
>> not, be
>> > useful to future researchers.
>> > >
>> > > Aloha,
>> > > Rich
>> > >
>> > >
>> > > _______________________________________________
>> > > Taxacom Mailing List
>> > > Taxacom at mailman.nhm.ku.edu
>> > > http://mailman.nhm.ku.edu/mailman/listinfo/taxacom
>> > >
>> > > The Taxacom Archive back to 1992 may be searched with either of these
>> > methods:
>> > >
>> > > (1) by visiting http://taxacom.markmail.org
>> > >
>> > > (2) a Google search specified as:
>> > > site:mailman.nhm.ku.edu/pipermail/taxacom  your search terms here
>> > >
>> > > Celebrating 26 years of Taxacom in 2013.
>> > >
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 11
>> Date: Tue, 7 May 2013 23:43:49 +0200
>> From: Sami Rabei <samirabei at mans.edu.eg>
>> Subject: [Taxacom] Paper Request Lazarides 1997
>> To: <taxacom at mailman.nhm.ku.edu>
>> Message-ID: <A333E16BEE7F47D69A639CD3283A11BB at wmad386c8d7356>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Dear All
>>
>> can any help me sending the following article:
>>
>>
>> Lazarides M 1997 A evision of Eragrostis Eragrostideae Eleusininae
>> Poaceae) in Australia Austral Syst Bot.10: 77-187.
>>
>> on the other hand, Many Thanks for Dr. Ford-Werntz, Herbarium Curator,
>> Associate Clinical Professor, Biology Dept., Box 6057, Life Sci. Bldg., 53
>> Campus Dr. West Virginia Univ. Morgantown, WV 26506
>> 304-293-0794; biology.wvu.edu
>>
>> for sending me the request previous paper
>>
>> =====
>>
>> All the best.
>>
>> Sami Rabei
>>
>> http://scholar.google.com/citations?user=GexZOhIAAAAJ
>>
>> Sincerely Yours
>>
>>  ----------------------------------
>> With my Best Wishes
>> Sami Hussein Rabei,
>> Botany Department
>> Faculty of Science,
>> Damietta University,
>> New Damietta , Post Box 34517
>> Damietta
>> Egypt .
>>
>> Tel. Mobile:   002 0127 3601618
>>                     002 0101 7895350
>> Tel. Work:     002 057 2403981
>> Tel. Home:    002 057 2403108
>> Fax:              002 057 2403868
>>
>> ------------------------------
>>
>> Message: 12
>> Date: Tue, 07 May 2013 14:44:53 -0700
>> From: Tom Schweich <tas27 at schweich.com>
>> Subject: Re: [Taxacom] Data quality of aggregated datasets
>> To: taxacom at mailman.nhm.ku.edu
>> Message-ID: <518975D5.2090105 at schweich.com>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> On 5/6/2013 12:32 PM, It was written:
>> > You're right.  We are dealing with raw data.  The work of the
>> > "aggregators" should first be to organise all of these raw data as an
>> > evidence-base for understanding the recorded distribution of any
>> species in
>> > time and space,
>> I would like to challenge the assertion that the "aggregators ...
>> organize ... [the] raw data."   I agree that maybe that's what they
>> *should* do, but something entirely different is actually happening.
>>
>> My case in point is the distribution of Frasera paniculata. The
>> aggregators will show that this taxon occurs in the state of Nevada.  I
>> disagree.  You may remember that I posted previously about this, stating
>> that my comments on GBIF and EOL from three years ago have had no
>> effect.  The staff at EOL responded very kindly saying that my comment
>> still lived there. I also learned that EOL gets its data from
>> DiscoverLife, which gets its data from GBIF, which gets its data from
>> USDA Plants.   They also gave me a URL through which I could direct
>> comments to USDA Plants.
>>
>> Following the chain of data aggregation, I went to the USDA Plants web
>> site.   There, I learned the source of "raw data" from which it was
>> determined that F. paniculata occurred in Nevada was: Kartesz, J.T.
>> 1988. A flora of Nevada. Ph.D. Dissertation.  This morning I went to the
>> library and read what the dissertation says about F. paniculata.  It
>> says "... reported from the Pahranagat Mts., Lincoln Co."     There is
>> no reported collector, no collection number, no date of collection, and
>> no voucher.
>>
>> I would assert that this is not RAW data.  It is, at best, aggregated
>> data, i.e., the writer aggregated or summarized what other unidentified
>> person(s) said.   At worst, it is completely false, perhaps caused by
>> the common error of mistaking F. albomarginata for F. paniculata.   Even
>> if you pick a middle point and say something like "it's a reasonable
>> speculation,"  by the time you get through the four layers of
>> aggregation, it's presented as fact.
>>
>> This just doesn't sound like "aggregators ... organize ... [the] raw
>> data" to me.  It sounds more like "aggregators aggregate other
>> aggregators' aggregated data."
>>
>> Whether USDA Plants will review the source (raw vs. aggregate) and
>> veracity of their data remains to be seen.  I posted a comment at USDA
>> plants. Now waiting for a response.
>>
>> --
>> Tom Schweich KJ6BIT tas27 at schweich.com
>> http://www.schweich.com
>> http://twitter.com/schweich
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 13
>> Date: Tue, 07 May 2013 14:55:54 -0700
>> From: Tom Schweich <tas27 at schweich.com>
>> Subject: [Taxacom] Accuracy of GPS Receivers, was: Re:  Data quality
>>         of aggregated datasets
>> To: taxacom at mailman.nhm.ku.edu
>> Message-ID: <5189786A.5060403 at schweich.com>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> On 5/7/2013 1:57 PM, Richard Pyle wrote:
>> > I'm not
>> > sure how such devices estimate the error radius, and I'm not sure how
>> the
>> > average field biologist would find out.
>> One week I frightened my neighbors by bicycling in a course between 7
>> known Control Points all within about 5 blocks of my house, taking GPS
>> measurements.  I made 14 circuits collecting 98 location measurements.
>> The RMS error of my GPS, a Garmin 76csx, is between 4-5 meters. There is
>> also a very distinct bias a few meters to the north northeast.  If I
>> could account for that bias I could say that the accuracy of my GPS was
>> 2-3 meters.
>>
>> --
>> Tom Schweich KJ6BIT tas27 at schweich.com
>> http://www.schweich.com
>> http://twitter.com/schweich
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 14
>> Date: Tue, 7 May 2013 19:20:36 -0400
>> From: Dave Vieglais <vieglais at ku.edu>
>> Subject: Re: [Taxacom] Data quality of aggregated datasets
>> To: Richard Pyle <deepreef at bishopmuseum.org>
>> Cc: TAXACOM <taxacom at mailman.nhm.ku.edu>
>> Message-ID: <30AB49FC-CF23-447E-9D9C-F898BA5C6948 at ku.edu>
>> Content-Type: text/plain; charset=us-ascii
>>
>> Hi Rich,
>> The confidence interval for the error estimate these devices provide
>> should be available in the specifications, though that may not be the case
>> in devices not warranted for instrumentation. Where it is available though,
>> it is useful to record in the metadata since this is helpful for analyses,
>> and where it's not, at least the device name and model should be noted.
>>
>> cheers,
>>   Dave V.
>>
>> On 2013.05.07, at 16:57-0400, Richard Pyle <deepreef at bishopmuseum.org>
>> wrote:
>>
>> > Hi Dave,
>> >
>> > My use of "+/-" was in reference to the accuracy of the GPS device.
>>  I'm not
>> > sure how such devices estimate the error radius, and I'm not sure how
>> the
>> > average field biologist would find out.  However, many GPS devices I've
>> used
>> > give me a simple number representing "Accuracy", expressed as a distance
>> > (usually in feet or meters).  That's a number I can easily capture as a
>> > radius.  How the GPS device generated that number, and what the basis
>> of the
>> > error estimate used by the GPS device is, may be a bit more cryptic.
>> >
>> > Aloha,
>> > Rich
>> >
>> >
>> >> -----Original Message-----
>> >> From: Dave Vieglais [mailto:dave.vieglais at gmail.com] On Behalf Of Dave
>> >> Vieglais
>> >> Sent: Tuesday, May 07, 2013 9:05 AM
>> >> To: Richard Pyle
>> >> Cc: TAXACOM
>> >> Subject: Re: [Taxacom] Data quality of aggregated datasets
>> >>
>> >> In addition, the confidence associated with the error estimate should
>> also
>> > be
>> >> recorded. For example, does "+/- 100m" refer to the 95% confidence
>> >> interval? Circular Error Probable (50%)? 3 sigma ellipse (98.9%)? etc.
>> >>
>> >> On 2013.05.07, at 13:20-0400, Richard Pyle <deepreef at bishopmuseum.org>
>> >> wrote:
>> >>
>> >>>> There is nothing wrong with collecting fine scale records on a GPS
>> >>>> using
>> >>> longitudes and latitudes, but when you are using a GPS there
>> >>>> is no need for a radius as the error is well within the walking
>> >>>> distance
>> >>> of most creatures.
>> >>>
>> >>> You should *always* capture the radius -- even for GPS coordinates.
>> >>> You cannot know in advance what the information will be useful for,
>> >>> and not all GPS devices record with the same accuracy.  A GPS with +/-
>> >>> 100m may be no different from one with +/- 10m if you are doing
>> >>> ecological analysis; but it could make a huge difference if your goal
>> >>> is to return to the same tree or coral head or whatever.  I think it's
>> >>> just silly to throw away information when it's easy to capture.  It's
>> >>> also silly to think you know in advance what information will, or will
>> > not, be
>> >> useful to future researchers.
>> >>>
>> >>> Aloha,
>> >>> Rich
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> Taxacom Mailing List
>> >>> Taxacom at mailman.nhm.ku.edu
>> >>> http://mailman.nhm.ku.edu/mailman/listinfo/taxacom
>> >>>
>> >>> The Taxacom Archive back to 1992 may be searched with either of these
>> >> methods:
>> >>>
>> >>> (1) by visiting http://taxacom.markmail.org
>> >>>
>> >>> (2) a Google search specified as:
>> >>> site:mailman.nhm.ku.edu/pipermail/taxacom  your search terms here
>> >>>
>> >>> Celebrating 26 years of Taxacom in 2013.
>> >>>
>> >
>> >
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 15
>> Date: Tue, 07 May 2013 19:34:35 -0400
>> From: Fred Schueler <bckcdb at istar.ca>
>> Subject: Re: [Taxacom] Data quality of aggregated datasets
>> To: taxacom at mailman.nhm.ku.edu
>> Message-ID: <20130507193435.19006ytsrkzs07t7 at webmail.ca.inter.net>
>> Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes";
>>         format="flowed"
>>
>> > On 2013.05.07, at 16:57-0400, Richard Pyle <deepreef at bishopmuseum.org>
>> wrote:
>> >
>> > My use of "+/-" was in reference to the accuracy of the GPS device.
>>  I'm not
>> > sure how such devices estimate the error radius, and I'm not sure how
>> the
>> > average field biologist would find out.  However, many GPS devices I've
>> used
>> > give me a simple number representing "Accuracy", expressed as a distance
>> > (usually in feet or meters).  That's a number I can easily capture as a
>> > radius.  How the GPS device generated that number, and what the basis
>> of the
>> > error estimate used by the GPS device is, may be a bit more cryptic.
>>
>> * empirically, at least in our driveway in eastern Ontario, and with a
>> Garmin 45, the "accuracy" number is similar to the standard deviation
>> of the positions over a span of years, and as recorded as a track.
>>
>> Schueler,  Frederick W. 2000. Navigating as Naturalists with the
>> Global Positioning System. Trail and Landscape 34(1):35-40.
>>
>> ...but I have no idea what they're supposed to represent.
>>
>> fred.
>> ------------------------------------------------------------
>>           Frederick W. Schueler & Aleta Karstad
>> Bishops Mills Natural History Centre - http://pinicola.ca/bmnhc.htm
>> Mudpuppy Night in Oxford Mills - http://pinicola.ca/mudpup1.htm
>> Daily Paintings - http://karstaddailypaintings.blogspot.com/
>>           South Nation Basin Art & Science Book
>>           http://pinicola.ca/books/SNR_book.htm
>>      RR#2 Bishops Mills, Ontario, Canada K0G 1T0
>>    on the Smiths Falls Limestone Plain 44* 52'N 75* 42'W
>>     (613)258-3107 <bckcdb at istar.ca> http://pinicola.ca/
>> ------------------------------------------------------------
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 16
>> Date: Wed, 8 May 2013 14:48:23 +1000
>> From: Robert Mesibov <mesibov at southcom.com.au>
>> Subject: Re: [Taxacom] Accuracy of GPS Receivers, was...
>> To: TAXACOM <taxacom at mailman.nhm.ku.edu>
>> Message-ID: <20130508144823.c33032de.mesibov at southcom.com.au>
>> Content-Type: text/plain; charset=US-ASCII
>>
>> Over a month last (austral) summer I took 2 readings a day (total 50
>> observations) with my old faithful Garmin eTrex (vintage 2005) from exactly
>> the same spot in my backyard, always allowing the readings to settle down
>> over the course of a minute or two.
>>
>> I recorded the date, time, location (UTM), elevation and declared
>> accuracy. You can download the raw data here:
>> http://www.polydesmida.info/GPS_repeats_Mesibov_2012.csv and use them as
>> you like.
>>
>> As expected, elevation was the most variable data item. I've heard it
>> rule-of-thumbed that GPS elevation precision is ca 1.5x horizontal
>> precision under the best of conditions.
>>
>> What's more important to understand is that GPS elevation is height above
>> an Earth model, not above sea level, and can be tens of metres different
>> from a.s.l. Comparing heights on 10m contour maps with heights from Google
>> Earth, I find Google Earth elevations are rarely more than 10m off.
>> --
>> Dr Robert Mesibov
>> Honorary Research Associate
>> Queen Victoria Museum and Art Gallery, and
>> School of Agricultural Science, University of Tasmania
>> Home contact: PO Box 101, Penguin, Tasmania, Australia 7316
>> Ph: (03) 64371195; 61 3 64371195
>>
>>
>>
>> ------------------------------
>>
>> Message: 17
>> Date: Wed, 8 May 2013 05:38:16 -0700
>> From: "Poly, William" <WPoly at calacademy.org>
>> Subject: Re: [Taxacom] Accuracy of GPS Receivers, was...
>> To: TAXACOM <taxacom at mailman.nhm.ku.edu>
>> Message-ID:
>>         <
>> 738D64B3AA244648AB7806422B8E13637CF4EE57C8 at MAILBOXCLUSTER.calacademy.org>
>>
>> Content-Type: text/plain; charset="us-ascii"
>>
>>
>> GPS accuracy has varied temporally due to restrictions by the US govt.
>> for military/security reasons (Selective Availablity).  See:
>>
>> http://www.gps.gov/systems/gps/performance/accuracy/
>> http://www.gps.gov/systems/gps/modernization/sa/
>> http://www.colorado.edu/geography/gcraft/notes/gps/gps.html
>>
>>
>> Bill
>>
>>
>> ________________________________________
>> From: taxacom-bounces at mailman.nhm.ku.edu [
>> taxacom-bounces at mailman.nhm.ku.edu] On Behalf Of Robert Mesibov [
>> mesibov at southcom.com.au]
>> Sent: Wednesday, May 08, 2013 12:48 AM
>> To: TAXACOM
>> Subject: Re: [Taxacom] Accuracy of GPS Receivers, was...
>>
>> Over a month last (austral) summer I took 2 readings a day (total 50
>> observations) with my old faithful Garmin eTrex (vintage 2005) from exactly
>> the same spot in my backyard, always allowing the readings to settle down
>> over the course of a minute or two.
>>
>> I recorded the date, time, location (UTM), elevation and declared
>> accuracy. You can download the raw data here:
>> http://www.polydesmida.info/GPS_repeats_Mesibov_2012.csv and use them as
>> you like.
>>
>> As expected, elevation was the most variable data item. I've heard it
>> rule-of-thumbed that GPS elevation precision is ca 1.5x horizontal
>> precision under the best of conditions.
>>
>> What's more important to understand is that GPS elevation is height above
>> an Earth model, not above sea level, and can be tens of metres different
>> from a.s.l. Comparing heights on 10m contour maps with heights from Google
>> Earth, I find Google Earth elevations are rarely more than 10m off.
>> --
>> Dr Robert Mesibov
>> Honorary Research Associate
>> Queen Victoria Museum and Art Gallery, and
>> School of Agricultural Science, University of Tasmania
>> Home contact: PO Box 101, Penguin, Tasmania, Australia 7316
>> Ph: (03) 64371195; 61 3 64371195
>>
>> _______________________________________________
>> Taxacom Mailing List
>> Taxacom at mailman.nhm.ku.edu
>> http://mailman.nhm.ku.edu/mailman/listinfo/taxacom
>>
>> The Taxacom Archive back to 1992 may be searched with either of these
>> methods:
>>
>> (1) by visiting http://taxacom.markmail.org
>>
>> (2) a Google search specified as:  site:
>> mailman.nhm.ku.edu/pipermail/taxacom  your search terms here
>>
>> Celebrating 26 years of Taxacom in 2013.
>>
>>
>> ------------------------------
>>
>> Message: 18
>> Date: Wed, 08 May 2013 10:23:07 -0300
>> From: "Piero Delprete" <piero.delprete at ird.fr>
>> Subject: Re: [Taxacom] Accuracy of GPS Receivers, was...
>> To: "Poly, William" <WPoly at calacademy.org>,     "TAXACOM"
>>         <taxacom at mailman.nhm.ku.edu>
>> Message-ID: <ximss-244790100 at mails.optimails.com>
>> Content-Type: text/plain;charset="utf-8"; format="flowed"
>>
>> Dear all,
>>
>> as I did a lot of field work in South America, I came to the conclusion
>> that
>> measuring altitude with a GPS is totally useless, unless your GPS can
>> receive at least 7-8 satellites. This is question of triangulation,
>> because
>> the tiniest fraction of an angle (from the satellite to your GPS) means a
>> huge difference in altitude. Which is not the case when measuring
>> location.
>>
>> In conclusion, for altitude, I still use the classic Thommen altimeter,
>> which, in my opinion, is more accurate then any GPS. Of course, there are
>> variation depending on the anthmospheric pressure, but still more accurate
>> the any GPS that capture only a few satellites. Of course, the Thommen
>> altimeter needs to be calibrated in a locality that we know the altitude
>> with certainty. Living close to sea makes it easier. Or, there are certain
>> places where the altitude has been measured with extreme accuracy, which
>> could also be a good test for GPS users.
>>
>> Well, this my two cents,
>> Piero
>>
>> Piero G. Delprete - Herbier de Guyane,  IRD - UMR AMAP, Boite Postale 165,
>> 97323 Cayenne Cedex, Guyane Francaise (French Guiana), France - Tel.
>> [0594]
>> 0594297250 - http://www.cayenne.ird.fr/aublet2
>>
>> On Wed, 8 May 2013 05:38:16 -0700
>>   "Poly, William" <WPoly at calacademy.org> wrote:
>> >
>> > GPS accuracy has varied temporally due to restrictions by the US
>> >govt. for military/security reasons (Selective Availablity).  See:
>> >
>> > http://www.gps.gov/systems/gps/performance/accuracy/
>> > http://www.gps.gov/systems/gps/modernization/sa/
>> > http://www.colorado.edu/geography/gcraft/notes/gps/gps.html
>> >
>> >
>> > Bill
>> >
>> >
>> > ________________________________________
>> >From: taxacom-bounces at mailman.nhm.ku.edu
>> >[taxacom-bounces at mailman.nhm.ku.edu] On Behalf Of Robert Mesibov
>> >[mesibov at southcom.com.au]
>> > Sent: Wednesday, May 08, 2013 12:48 AM
>> > To: TAXACOM
>> > Subject: Re: [Taxacom] Accuracy of GPS Receivers, was...
>> >
>> > Over a month last (austral) summer I took 2 readings a day (total 50
>> >observations) with my old faithful Garmin eTrex (vintage 2005) from
>> >exactly the same spot in my backyard, always allowing the readings to
>> >settle down over the course of a minute or two.
>> >
>> > I recorded the date, time, location (UTM), elevation and declared
>> >accuracy. You can download the raw data here:
>> >http://www.polydesmida.info/GPS_repeats_Mesibov_2012.csv and use them
>> >as you like.
>> >
>> > As expected, elevation was the most variable data item. I've heard
>> >it rule-of-thumbed that GPS elevation precision is ca 1.5x horizontal
>> >precision under the best of conditions.
>> >
>> > What's more important to understand is that GPS elevation is height
>> >above an Earth model, not above sea level, and can be tens of metres
>> >different from a.s.l. Comparing heights on 10m contour maps with
>> >heights from Google Earth, I find Google Earth elevations are rarely
>> >more than 10m off.
>> > --
>> > Dr Robert Mesibov
>> > Honorary Research Associate
>> > Queen Victoria Museum and Art Gallery, and
>> > School of Agricultural Science, University of Tasmania
>> > Home contact: PO Box 101, Penguin, Tasmania, Australia 7316
>> > Ph: (03) 64371195; 61 3 64371195
>> >
>> > _______________________________________________
>> > Taxacom Mailing List
>> > Taxacom at mailman.nhm.ku.edu
>> > http://mailman.nhm.ku.edu/mailman/listinfo/taxacom
>> >
>> > The Taxacom Archive back to 1992 may be searched with either of
>> >these methods:
>> >
>> > (1) by visiting http://taxacom.markmail.org
>> >
>> > (2) a Google search specified as:
>> > site:mailman.nhm.ku.edu/pipermail/taxacom  your search terms here
>> >
>> > Celebrating 26 years of Taxacom in 2013.
>> > _______________________________________________
>> > Taxacom Mailing List
>> > Taxacom at mailman.nhm.ku.edu
>> > http://mailman.nhm.ku.edu/mailman/listinfo/taxacom
>> >
>> > The Taxacom Archive back to 1992 may be searched with either of
>> >these methods:
>> >
>> > (1) by visiting http://taxacom.markmail.org
>> >
>> > (2) a Google search specified as:
>> > site:mailman.nhm.ku.edu/pipermail/taxacom  your search terms here
>> >
>> > Celebrating 26 years of Taxacom in 2013.
>>
>> Piero G. Delprete - Herbier de Guyane,  IRD - UMR AMAP, Boite Postale 165,
>> 97323 Cayenne Cedex, Guyane Francaise (French Guiana), France - Tel.
>> [0594]
>> 0594297250 - http://www.cayenne.ird.fr/aublet2
>>
>>
>>
>> ------------------------------
>>
>> Message: 19
>> Date: Wed, 8 May 2013 14:38:34 +0000
>> From: Peter Rooney <P.Rooney at student.reading.ac.uk>
>> Subject: [Taxacom] Plant nomenclatural issues
>> To: "taxacom at mailman.nhm.ku.edu" <taxacom at mailman.nhm.ku.edu>
>> Message-ID:
>>         <
>> AC937770CA00D64D8FB693836123E300182A3E61 at AMXPRD0112MB613.eurprd01.prod.exchangelabs.com
>> >
>>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Dear all,
>>
>> I'd be really grateful for some help with plant nomenclatural questions.
>>  I'm using a 1950 paper which uses the following notation with reference to
>> synonyms of a Linnaean species.  The synonymy uses "pro parte typica quoad"
>> and "pro parte non typica quoad", which I understand to mean part of the
>> type or part of a non-type, "with regards to", but then it refers to an
>> area, author, herbarium etc., which I'm not clear about  If anyone could
>> explain what these references mean, it would be really helpful.
>>
>> e.g.
>>
>> C. Papyrus Auct. non L. ; Clarke, l. c., p. 374 (1901) p. p. n. t. qu.
>> Mozambique Dist. (Whyte).
>> C. Papyrus Auct. non L. ; Boeck., l. .c, p. 555 (1879) p. p. n. t. qu.
>> Naumann 138 et Soy aux 106.
>> C. Papyrus Auct. non L. ; Lam., l. c., p. 147 (1791) p. p. n. t. qu.
>> herb. (e Ma dagascaria).
>> C. Papyrus L., Sp. Pl., ed. 1, p. 47 (1753) p. p. t. qu. herb, et syn. C.
>> Bauh. p. p.. Moris, p. p., Monti, Scheuchz., Micheli p. p. et Van Royen p.
>> p.
>>
>> Many thanks,
>>
>> Regards
>>
>>
>> Peter
>>
>> Peter
>>
>>
>> ------------------------------
>>
>> Message: 20
>> Date: Wed, 8 May 2013 17:48:20 +0200
>> From: Sami Rabei <samirabei at mans.edu.eg>
>> Subject: Re: [Taxacom] Paper Request Lazarides 1997
>> To: <taxacom at mailman.nhm.ku.edu>
>> Message-ID: <73C36B41225E483AA118CA49563DD67B at wmad386c8d7356>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> I received the article.
>> Many Thanks for Dr. Reveal , Dr. Novikoff, Dr. Zurcher and Dr. Wilson,
>>   ----- Original Message -----
>>   From: Sami Rabei
>>   To: taxacom at mailman.nhm.ku.edu
>>   Sent: Tuesday, May 07, 2013 11:43 PM
>>   Subject: Paper Request Lazarides 1997
>>
>>
>>   Dear All
>>
>>   can any help me sending the following article:
>>
>>
>>   Lazarides M 1997 A evision of Eragrostis Eragrostideae Eleusininae
>> Poaceae) in Australia Austral Syst Bot.10: 77-187.
>>
>>   on the other hand, Many Thanks for Dr. Ford-Werntz, Herbarium Curator,
>> Associate Clinical Professor, Biology Dept., Box 6057, Life Sci. Bldg., 53
>> Campus Dr. West Virginia Univ. Morgantown, WV 26506
>>   304-293-0794; biology.wvu.edu
>>
>>   for sending me the request previous paper
>>
>>   =====
>>
>>   All the best.
>>
>>   Sami Rabei
>>
>>   http://scholar.google.com/citations?user=GexZOhIAAAAJ
>>
>>   Sincerely Yours
>>
>>    ----------------------------------
>>   With my Best Wishes
>>   Sami Hussein Rabei,
>>   Botany Department
>>   Faculty of Science,
>>   Damietta University,
>>   New Damietta , Post Box 34517
>>   Damietta
>>   Egypt .
>>
>>   Tel. Mobile:   002 0127 3601618
>>                       002 0101 7895350
>>   Tel. Work:     002 057 2403981
>>   Tel. Home:    002 057 2403108
>>   Fax:              002 057 2403868
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Taxacom Mailing List
>> Taxacom at mailman.nhm.ku.edu
>> http://mailman.nhm.ku.edu/mailman/listinfo/taxacom
>>
>> The entire Taxacom Archive back to 1992 may be searched with either of
>> these methods:
>> Visit: http://taxacom.markmail.org
>> Or use a Google search specified as:  site:
>> mailman.nhm.ku.edu/pipermail/taxacom  your-search-terms-here
>>
>> Celebrating 26 years of Taxacom in 2013.
>>
>> End of Taxacom Digest, Vol 86, Issue 7
>> **************************************
>>
>
>



More information about the Taxacom mailing list