JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for FISH Archives


FISH Archives

FISH Archives


FISH@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

FISH Home

FISH Home

FISH  2001

FISH 2001

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

The usual Continued

From:

garibaldino <[log in to unmask]>

Reply-To:

The Forum for Information Standards in Heritage (FISH)

Date:

Wed, 3 Oct 2001 20:39:42 +0100

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (96 lines)

Hello

my tuppence worth on fuzzy space is possibly a fudge, but here goes.

When I worked in Worcestershire SMR (Usual caveats about official policy
apply, though I no longer work for them anyway) we discussed the problem of
data which had dodgy locational info. One suggestion (I forget whose, so
wont take any credit/blame) was the idea of a 'parish polygon', which linked
to records which could fit into that parish. This answer was suggested in
response to VCH/Domesday data, where you might be able to tell Parish, but
not more precise info, and at least could flag up the possibility of unknown
sites being relevant to Dc work/smr search/whatever. This could be on a
seperate layer etc, and turned on and off as necessary, and records could be
removed from the Parish Polygon if more accurate information was made
available. That would not work for the Anytown barrow (bottom) but might
help with some problems.

I think also the thing to consider is that, in my view, the SMR/GIS is a
guide, not a be all and end all. Only when all available data has been
looked at can you determine what the edge of a polygon means. That means
that if its an excavation report, it will be obvious that the edge is the
edge of the event, not neccessarily the monument. As a monument is a
nebulous entity interpreted from all the event info, doesnt this mean that a
polygon is a snap shot of someone's judgement of a monuments extents, at the
time the polygon was drawn, rather than a definitive description? In which
case, each polygon can be seen more as a freeze frame of an ongoing process,
rather than an end point of that process. If that is so, then the problem of
boundaries is less of an issue, as archaeologists can (and do, often, and
usually loudly) disagree over their interpretations. The key thing, though,
is to make sure that the idea of what a polygon is representing is clear to
whomever gets the data. And this view of what the polygon represent can also
change as the data is cleaned, more data added, and the edges become more co
nfident. Please correct me if I have confused myself.

Having re-read the above paragraph, I think that the suggestion of a
confidence level associated with the polygon edges seems like an
increasingly good idea. This could also be done in levels so eg Level 1 was
a point in the general area, level 2 is a polygon guestimate, etc. An
individual record could progress up the levels as the data was cleaned,
checked and added to, but some records may never be able to progress due to
incomplete/inaccurate data recording/lost data.

Finally, the point about standard symbols potentially has more importance
for exporting SMR/GIS data than importing it. If the data standard is robust
enough, we can import any data and make if fit the standards we want.
Exporting it should perhaps be done to a more universal standard. Eg In
Durham (standard Caveats apply again), we are in the process of exporting
our data for one of the districts so the Planners can look at it in regard
to PLanning policies/applications, and call us if they need advice. Only
limited info is being migrated (grid refs (the data is mainly points, thogh
current SAM's have been polygoned); name and Smr number, to allow easy
communication. Training will also be given to help the planners understand
what they are looking at. But it would be useful if we could provide that
info so that say earthworks showed up differently to AP's, and Find spots
differently to SAM's. The point about exporting Standards is relevant
because I would be happier knowing that any theme providing such info had
some guidelines created by archaeologists, rather than council IT staff or
Planner (no disrespect to them, but they arent archaeologists). Have any
other people out there done this sort of data provision, and if so how did
they deal with this issue (if they considered it an issue!)

Nick Boldrini
Assistant Archaeology officer
Durham County Council
(From Home email)
The views in this email are my own, and not Durham County Council Official
Policy

Peter iles Wrote:

> One such is 'Fuzzy Space'i.e.
> what you do with sites that are insufficiently well spatially referenced,
> e.g. Mr Smith reported a prehistoric burial mound 'near Anytown'.  If you
> accept this as a valid site - Mr Smith may have provided sufficient
> information to show that it wasn't made up - then how do you plot it on
the
> SMR?  The paper map approach adopted in this SMR back in the 1970's was to
> write the SMR number assigned to it on the margin of the OS 1:10,000
quarter
> sheet that contained 'Anytown' with a pencil line joining the number to
the
> placename on the map.  This is not a solution on a GIS where a site needs
a
> definite location.  Drawing a polygon on the GIS to surround 'Anytown' is
a
> possible solution, but where do you set the boundaries?  Come to that how
> (without full excavation information) do you set the polygon boundaries
for
> the majority of site types? few will have clear, definable edges you can
> draw a line around.  You can use your professional
judgement/estimate/guess
> boundaries, but what we really need is a boundary that shades out, rather
> than an abrupt line.  Unfortunately this is not yet available in ArcView.
> This is perhaps just a practical reflection of a more theoretical
> difficulty, but is still important.

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

April 2024
February 2024
December 2023
September 2023
June 2023
May 2023
April 2023
March 2023
February 2023
January 2023
November 2022
October 2022
August 2022
May 2022
April 2022
March 2022
February 2022
January 2022
November 2021
October 2021
September 2021
May 2021
April 2021
March 2021
February 2021
October 2020
September 2020
May 2020
April 2020
March 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
March 2019
February 2019
January 2019
December 2018
October 2018
May 2018
March 2018
February 2018
January 2018
December 2017
October 2017
August 2017
July 2017
June 2017
April 2017
March 2017
January 2017
December 2016
November 2016
September 2016
July 2016
June 2016
February 2016
January 2016
October 2015
September 2015
August 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
November 2014
October 2014
September 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
October 2012
July 2012
June 2012
May 2012
February 2012
January 2012
November 2011
October 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
2006
2005
2004
2003
2002
2001
2000
1999


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

For help and support help@jisc.ac.uk

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager