Month: March 2019

Looking at producing a couple of Binder buttons for a demo repo (ouseful-demos/choropleth-map-demo) in which I wanted to launch directly into a notebook in one case, a ScriptedForm demo in another, I noticed that there are two variants for launching into MyBinder location: ?filepath= and ?urlpath=.

Via @minrk in the Binder gitter channel:

[B]oth result in different urls when redirecting the user to the running binder.

• urlpath is appended unmodified, so that it goes to hub.mybinder.org/user/xyz/{urlpath}
• filepath is a location of a file in the repo, so filepath=index.ipynb gets turned into e.g. hub.mybinder.org/user/xyz/notebooks/index.ipynb to open that file.

urlpath requires knowledge of the notebook server’s url scheme, but can land you anywhere you like. filepath doesn’t require that knowledge, but can do fewer things (e.g. just open a notebook or directory).

Handy, and good to know…

 

 

Staying with a conveyancer friend over the weekend, conversation got on to the topic (as it does…) of whether I could poison pill the bottom half of our garden by selling patches of the land to other people that would make it difficult for a future owner of the house to sell the land for development. It seems it’d be easy enough to write an agreement sell small parcels of land, but with it would come a right of access for the new owner, which would create a right of way through the rest of the garden to that piece of land.

Discussion then moved to the practices of developers of new builds. The house we were staying in was on a development with off-road parking for one (at a push, two) cars, plus a garage. In the centre of the development were additional, numbered parking areas allocated to certain houses, for a fee. Signs loudly declared the private land nature of these spaces with warnings about fines for unauthorised use.

In many cases, it seems that developers are also creating developments where the road access remains a private road, unadopted by the local authority. According to Private, or ‘unadopted’ roads in England and Wales,  House of Commons Library Briefing Paper SN00402:

There are two main types of private or unadopted road: those on new developments such as housing estates and those which, usually by historic accident, have existed for a long time, often since the nineteenth century.

…

The law on the maintenance and adoption of private roads in England and Wales is highly complex. It is largely contained in Part XI of the Highways Act 1980. Briefly, a private or unadopted road is by definition a highway not maintainable at public expense. The local highway authority is therefore under no obligation to pay for its maintenance. Responsibility for the cost of maintaining a private road rests with the frontagers (the owners of properties which front onto such roads).

…

[The Act] further requires every local highway authority (unitary and county councils) “cause to be made, and shall keep corrected up to date, a list of the streets within their area which are highways maintainable at the public expense”.

But presumably there is no list of unadopted roads.

I don’t recall offhand what, if anything, the Isle of Wight’s recent planning consultation had to say about the desirability, or otherwise, of adoption of roads on any new builds applied for in allocated planning areas. But this retention of the private ownership of roads by developers rather than their admittance into the public realm, is another example of the erosion of ownership rights in favour of negotiated rights of way or management fees and rental agreements associated with communal areas in the “wider estate” of the development on which you live. You did read all the terms of the license agreement before you clicked “yes”, didn’t you?

The briefing also notes on the subject of parking:

Generally, there is no general right to park in a private or unadopted road except for the owner of the road. In practice parking may be permitted or tolerated by the owner (in which case there is a licence to park) and in some cases a legal right may have been granted by the owner. As Barsby [Private Roads: The Legal Framework (5th ed.), 2013] explains, parking in a private or unadopted road without permission or a legal right to do so is trespassing, and is a civil wrong for which redress can be obtained. The wrong is done to the owner of the road or, if different, the person in possession of it[.]

So if you try to park on the (private) road outside your house…

As described in Homeowners trapped by ‘fleecehold’ – the new cash cow for developers, The Guardian, 2 Dec 2017:

Thousands of homeowners on private estates are facing unregulated and uncapped maintenance fees, amid allegations that developers have created a cash cow from charging for communal areas not maintained by the council. Management contracts for “unadopted” private estates are frequently sold off to speculators and property management companies in the same way as freeholds and ground rents – leaving homeowners with spiralling fees and nowhere to turn. If a new-build estate is “unadopted” it means communal areas such as roads, grass verges, pavements and playgrounds are retained by the developer. The developer then usually sub-contracts day-to-day management.

Which makes absolute sense for the developers. In the first case, it is likely to be cheaper for developers not to take the road fully up to the standard required for adoption. If such costs are typically passed on to original buyers, this should have the effect of reducing the first sale price of each dwelling. Which is good for consumers, right? Good for affordability? Only, it isn’t, because in perpetuity you may well have to pay a drip-drip amount that will make the total cost of ownership more expensive.

Developments that do not end with adoption of roads may also be attractive to councils because it means they aren’t directly tasked with maintenance of the new roads. (I wonder: could planning applications actually be refused by the local authority if they don’t want to enter into “Section 38 ” agreements to adopt roads submitted as part of the planning application?)

A post on the New Home Blog — Why are private roads so common on new housing developments?, May 4th, 2016— identifies several other possible disadvantages, including: maintenance costs for shared driveways and sewer drainage; clearing up contaminated land if the home was built on a brownfield site; serious disrepair, [in which case] local authorities have discretionary powers to improve the standard of any privately-owned street at any time and [require] contribut[ions] to the cost.

Private roads may also be narrower than publicly adopted roads and with lower specification street lighting.

The post also suggests that “[t]he Local Authority will probably not: grit the roads in icy conditions or clear heavy snowfall; carry out road sweeping or drain gully clearance. Refuse collections may not even enter the private road.

There may be a way for home-owners on a development to extend the public realm though. As the HoCL briefing describes, home owners are in a position to request adoption of the road, if enough of them agree:

Section 228(7) states that, where all street works in a private street have been executed to the satisfaction of the street authority, the street authority shall declare adoption of the street if so requested by the owners of properties which together account for more than half the rateable value of the street: If all street works (whether or not including lighting) have been executed in a private street to the satisfaction of the street works authority, then, on the application of the majority in rateable value of the owners of premises in the street, the street works authority shall, within the period of 3 months from the date of the application, by notice displayed in a prominent position in the street, declare the street to be a highway which for the purposes of this Act is a highway maintainable at the public expense and thereupon the street shall become such a highway.

However, even there the developers may try to stymie that. As the New Home Blog post warns:

Buyers should also be aware of housebuilders adding a clause like this: “17. Not to make support or procure any application to secure the adoption of the Estate Roads as publicly maintained highways pursuant to Section 228 of the Highways Act 1980 or any statutory re-enactment thereof or any other similar statutory provisions and if required by the Landlord to object to any such application.”

You did read the terms and conditions, right? And think the consequences of them through? (That must surely be an unfair contract term, mustn’t it?)

PS one for me to go back to check on the Isle of Wight Planning consultation: was there any mention of section 38 adoption in the document? Are there any metrics regarding tracking of section 38 adoption on developments pursued on allocated areas? Is the council interested in the extent to which home owners on new developments are likely to be tied into maintenance agreements arising from builds on private roads owned by the developers or thence sold on to management companies, particularly for “affordable” developments? Would the council seek to protect the rights of home owners by rejecting applications for developments that included clauses like a possible “clause 17” as identified above?

Each new year, one of my half-made resolutions is to pull together an opendata hub for my local area. Being an island, the clear boundary also provides opportunities for monitoring inflows and outflows that may be harder to identify in other areas.

And each year, it never happens, although each year I do dabble a bit with local data gleaned from national datasets.

So this year, I’m gonna to try to start pulling recipes into one place, and try to get into the habit of adding new datasets as tables in the same database. The database model will probably be hit and miss, but I’ll try to work out sensible primary and secondary keys where I can. A Linked Data model would probably make most sense, but having to spend time getting the modelling right is too much of an overhead and a distraction.

A couple of things I want to try to achieve:

• producing recipes that scale out; my interest is in grabbing and representing data from national datasets at a local level. The recipes should be easily keyed with identifiers that allow views to be rendered as easily for other areas as for the Isle of Wight;
• producing some sort of consistent workflow and coherent architecture where I can easily add more data views whenever I get to grips with a new dataset.

A great example of this, and one I really should take a couple of days holiday off to work in, comes in the form of the Trafford Datalab Ward profiler.

This is just packed with goodness:

• the ability to select different data topics and subtopics within those;
• choropleth maps and associated, sorted lollipop charts (the only chart type that looks to be supported at the moment);
• the ability to download the data;
• the ability to see the R code used to grab the data.

The source for the site / app is available as traffordDataLab/ward_profiler and the data and data grabbers can be seen at traffordDataLab/ward_data/.

The ward_data repo is such a lovely, simple idea: topic areas with separate R code files to grab the data for a particular subtopic and dump it as a CSV.

Columns are normalised to:

area_code	area_name	indicator	period	measure	unit	value

The R code often seems to pull local data from national datasets using literal, embedded codes, but it would be too much overhead to recast all these as arguments and pop them at the top of each file where they can be easily changed, or provide a means of passing them into the file from a parameter file.

The next step might them be to automate the production of the parameter file from a text look-up (eg “Isle of Wight”, “Trafford”) against various code lookup tables.

My first impression was that it could also make sense to extract mutables, such as URLs (data URLs often change with updated datasets) into a separate file too, or at least parameterise them and move them to the top of the R files. But new version datafiles relating to a particular dataset sometimes require tweaks to parsers, even if the datasets are nominally the same. This issue of consistency is one of the downsides of data released as files (CSV etc) rather than accessed via an API. (The advantage is that you can often get the bulk data more easily as a file…) But it would make more sense (using the file based data grab route) to version each data grabber file, creating an ongoing series of forks for each new release, rather than change the last most recent version directly. This would also ensure that history keeps working and would let you compare datasets over several releases. It would still make sense to pull  codes and URLs etc out into parameters at the top of the file. The codes at the top (a user area), to allow folk to easily grab data for another area; then the URLs in a maintenance area below, that could be readily changed when updating the file for a different release of the same data.

On the other hand, moving to API datagrabs may make more sense still. The R statxplorer from the House of Commons Library’s Oli Hawkins could help there, at least when pulling on data from the DWP Stat-Xplore API (Stat-Xplore website).

The way the Trafford Data Lab have arranged their spatial datasets is also interesting  — a repo containing shapefiles for different boundaries: traffordDataLab/spatial_data, which look like they might well have been pulled from the ONS geoportal boundaries collection and then converted to geojson. (One thing I think that could be useful would be a set of recipes for generating the different boundary sets identified by the Trafford data for arbitrary local authority areas. (i.e. allowing users to extract data for just their local area from a national dataset). related to this, I have a crude sketchbook here showing how to to grab some of the boundaries into a simple spatialite database.)

As well as the ward profiler, the Trafford Data Lab have also produced a range of other single web page apps that are generated from code that extracts local data from national datasets and constructs the a static index.html file that defines the app.

For example, this road traffic accident app:

is generated from a single Rmd file that can be found in this repo.

The Trafford Data Lab approach is elegant in so many ways: standardised data tables; scripts for pulling data into standardised data tables at a local level from national datasets; a ward data viewer that scales easily just by adding another item to a form in the single page web app that defines it; bespoke single web page app generators that build static single page web apps containing just the local data they need extracted from national datasets.

I’m not sure if a similar approach is being followed by folk over at the House of Commons Library, but they also seem to have got onto a roll lately with their Constituency Dashboards.

These dashboards scale views at a constituency level (with displays often rendered at ward level, or other smaller appropriate geographical area within the constituency:

The apps are built on top of Microsoft Power BI, and while code doesn’t appear to be available, you can grab the constituency level data from the app:

Some of the apps are also paged, though it seems that in some cases that’s not working so well… I don’t like the social media trackers much either…

PS To do: it’s been a long time since I had a look around the open data space. On the to do list: check out what ODI Leeds have been up to recently (repos). For example, West Yorkshire Mapping looks interesting… or at least, it would be if recipes for generating those different geodata slices were available too… Bath Hacked is another group who’s recent projects I need to catch up with (repos, though they looked to have stalled somewhat?). Data Plymouth / DataPlay is another, though I always used to find it hard to find any actual code outputs from their events…?