text:
Financial Express (Holdings) Limited ("we", "our", "us" and derivatives) are committed to protecting and respecting your privacy. This Privacy Policy, together with our Terms of Use, sets out the basis on which any personal data that we collect from you, or that you provide to us, will be processed by us relating to your use of any of the below websites ("sites").
For the purposes of the Data Protection Act 1998, the data controller is Trustnet Limited of 2nd Floor, Golden House, 30 Great Pulteney Street, London, W1F 9NN. Our nominated representative for the purpose of this Act is Kirsty Witter.
We collect information about you when you register with us or use any of our websites / services. Part of the registration process may include entering personal details & details of your investments.
We may collect information about your computer, including where available your operating system, browser version, domain name and IP address and details of the website that you came from, in order to improve this site.
You confirm that all information you supply is accurate.
In order to provide personalised services to and analyse site traffic, we may use a cookie file which is stored on your browser or the hard drive of your computer. Some of the cookies we use are essential for the sites to operate and may be used to deliver you different content, depending on the type of investor you are.
You can block cookies by activating the setting on your browser which allows you to refuse the setting of all or some cookies. However, if you use your browser settings to block all cookies (including essential cookies) you may not be able to access all or part of our sites. Unless you have adjusted your browser setting so that it will refuse cookies, our system will issue cookies as soon as you visit our sites.
We store and use information you provide as follows:
We may also send you emails to provide information and keep you up to date with developments on our sites. It is our policy to have instructions on how to unsubscribe so that you will not receive any future e-mails. You can change your e-mail address at any time.
In order to provide support on the usage of our tools, our support team need access to all information provided in relation to the tool.
We will not disclose your name, email address or postal address or any data that could identify you to any third party without first receiving your permission.
However, you agree that we may disclose to any regulatory authority to which we are subject and to any investment exchange on which we may deal or to its related clearing house (or to investigators, inspectors or agents appointed by them), or to any person empowered to require such information by or under any legal enactment, any information they may request or require relating to you, or if relevant, any of your clients.
You agree that we may pass on information obtained under Money Laundering legislation as we consider necessary to comply with reporting requirements under such legislation.
We want to ensure that the personal information we hold about you is accurate and up to date. You may ask us to correct or remove information that is inaccurate.
You have the right under data protection legislation to access information held about you. If you wish to receive a copy of any personal information we hold, please write to us at 3rd Floor, Hollywood House, Church Street East, Woking, GU21 6HJ. Any access request may be subject to a fee of £10 to meet our costs in providing you with details of the information we hold about you.
The data that we collect from you may be transferred to, and stored at, a destination outside the European Economic Area ("EEA"). It may be processed by staff operating outside the EEA who work for us or for one of our suppliers. Such staff may be engaged in, amongst other things, the provision of support services. By submitting your personal data, you agree to this transfer, storing and processing. We will take all steps reasonably necessary, including the use of encryption, to ensure that your data is treated securely and in accordance with this privacy policy.
Unfortunately, the transmission of information via the internet is not completely secure. Although we will do our best to protect your personal data, we cannot guarantee the security of your data transmitted to our sites; any transmission is at your own risk. You will not hold us responsible for any breach of security unless we have been negligent or in wilful default.
Any changes we make to our privacy policy in the future will be posted on this page and, where appropriate, notified to you by e-mail.
Our sites contain links to other websites. If you follow a link to any of these websites, please note that these websites have their own privacy policies and that we do not accept any responsibility or liability for these policies. Please check these policies before you submit any personal data to these websites.
If you want more information or have any questions or comments relating to our privacy policy please email [email protected] in the first instance.
Havelock Europa PLC
7 September 2001
7 September 2001
Substantial Acquisition
* Havelock, the retail interiors and point of sale display business,
announces the acquisition of McIntosh 88 Ltd and its subsidiary, ESA
McIntosh, the UK market leader in the design, manufacture and installation
of educational science laboratories.
* In the year ended 31 December 2000, McIntosh made an audited pre-tax
profit of £932,000 on turnover of £13.3 m. McIntosh's trading results in
the seven months to end July 2001 have been significantly ahead of the
equivalent period of the previous year.
* An initial consideration of £3m will be paid at Completion. Further
consideration of up to £5m will be payable dependent on McIntosh's pre-tax
profit in both 2001 and 2002. The maximum additional consideration of £5m
will only be payable if McIntosh's pre-tax profit in both 2001 and 2002
reaches £3m. Other than the issue of 2,800,000 new Havelock shares, valued
at approximately £882,000, the acquisition will be bank financed.
* The Board resolved to look for opportunities to develop the business
further into areas, offering prospects of enhanced returns, which also
build on the Company's existing resources and skills as well as lessening
the Company's traditional dependence on the non-food retail sector.
* The directors believe that the acquisition of McIntosh will have the
following key commercial benefits:
+ the entry of the Group into a market where there is the opportunity
for significant growth and attractive returns and in which McIntosh
has already established a strong foothold;
+ the integration into the Group of a business which is geographically
close to Havelock's headquarters, involving similar production
processes to those used by Havelock and where the Group's established
manufacturing skills can be brought to bear to support growth and
enhance profit;
+ the opportunity to increase the efficiency of the combined business
through significant asset rationalisation; and
+ a more even manufacturing work flow, as a result of the seasonal
demand for McIntosh's products falling earlier in the year than that
of Havelock, thereby enabling an improved utilisation of the
manufacturing resources of the Enlarged Group.
* The acquisition is subject to Havelock shareholders' consent at an EGM
to be held on 24 September. A circular will be posted shortly.
* Michael Kennedy, Chairman, stated 'McIntosh is an excellent fit with
Havelock, with considerable scope for enhancement in earnings per share.
McIntosh matches our strategic criteria and follows earlier successful
initiatives to broaden Havelock's business into areas with significant
growth prospects.' *
Interim Results
* In what is traditionally the much weaker half of the year, Havelock
recorded a pre-tax loss of £1,493,000 (2000: loss £1,413,000) on a
turnover of £24.3 m (2000: £25.7 m), reflecting mixed trading, as
indicated at the AGM on 29 June 2001.
* A maintained interim dividend per share of 0.5p is declared.
* Retail Interiors' turnover was sharply down at £11.4 m (2000: £14.1 m)
reflecting difficult trading conditions in the retail fashion industry and
a significant reduction in the volume of work done for Marks & Spencer.
* Point of Sale Display's turnover increased to £10.2 m (2000: £10.1 m)
as a result of increased penetration of the supermarket sector with
Safeway becoming a more significant customer offsetting a reduction in
business with Arcadia. Volumes of business with BHS also grew strongly.
* Havelock's share of the operating profit of the Middle East retail and
hotels interiors joint venture increased to £373,000 from £64,000.
* Net debt of £10.8 m at 30 June 2001 compares with £15.1 m a year
* With regard to prospects, Michael Kennedy, Chairman, stated 'The level
of activity in the Retail Interiors Division is likely to be substantially
less than in 2000 and, with difficult and volatile conditions persisting,
it is too early to predict the outcome for this year with certainty.
However, lower volumes of business in Retail Interiors are likely to be
partly offset by a strong recovery at Showcard Print and a much increased
contribution from the Middle East, where prospects are most encouraging.'
Havelock Europa 01383-82 00 44
Hew Balfour (Chief Executive)
Graham MacSporran (Finance Director)
Noble Grossart 0131-226 7011
Guy Stenhouse
Bankside Consultants
Charles Ponsonby 020-7444 4166
* Nothing in this announcement should be construed as a profit forecast or be
interpreted to mean that the future earnings per share of the Company
following the acquisition will necessarily be greater than the historic
published earnings per share of Havelock.
ACQUISITION OF McINTOSH
Havelock Europa's original core business was the fitting out of retail stores.
In the mid 1990's the board concluded that the demand for traditional retail
shopfitting was likely to reduce and become more volatile. The Board therefore
embarked on a strategy to develop the business into areas which were
complementary to its existing activities and which had the potential to
enhance profitability.
The first element of this strategy was to develop Havelock Europa's presence
in the financial services market and the second was to build, through
acquisition, a point of sale display division. Later, in 1998 the Company also
extended its storefitting business into the Middle East through a joint
venture. Each of these initiatives has proven to be beneficial to the Company.
Havelock Europa is now one of the leading UK providers of retail interiors to
the financial services industry, most notably refitting branches for Bank of
Scotland but also working for Lloyds TSB, HSBC and Barclays. More recently
this activity has been curtailed as a result of the mergers and potential
mergers in this sector. However, the directors believe that this area will
continue to offer opportunity for growth once the recent spate of corporate
activity in the sector is concluded.
In point of sale display the Company acquired three businesses, Showcard Print
and Showcard Display in 1996, followed by Hartcliffe in 1997. These have
successfully established themselves as Havelock Europa's point of sale display
division which is trading strongly in the current year assisted by increased
penetration of the supermarket sector. The board believes this division has
the potential for further growth.
The Middle East joint venture is trading particularly well. As reported in the
results for the six months to 30th June 2001, Havelock Europa's share of the
operating profits of the joint venture in the period amounted to £373,000,
which compares with £64,000 in the equivalent period of the previous year. On
29th June 2001 the Company announced that the joint venture had reached
conditional agreement to acquire the factory and fixed assets of the Bahrain
Light Industries Company enabling the joint venture to meet its aspirations
for continuing growth. Prospects for the joint venture are good.
Notwithstanding these initiatives, the Company's profitability remains well
below that achieved in earlier years and well below what the board believes is
The Company is experiencing difficult and unpredictable markets in its UK
retail interiors arm, where fashion retail continues to suffer from mixed
fortunes, and also reduced investment in the financial services market as a
result of the number of actual and potential acquisitions and mergers in that
sector. Together with particularly fierce competition in the retail supply
chain and an increasing trend towards a pronounced seasonality in favour of
the second half, these factors have created more difficult trading conditions.
Although the board expects some recovery in the medium term it believes that
the retail market is likely to remain difficult and unpredictable for some
In the light of this difficult background and following discussions with
shareholders the board committed publicly to pursue actively options which
would maximise shareholder value. The Company, with the assistance of its
financial advisers, has, over a prolonged period, developed and evaluated a
number of initiatives, in order to determine whether there might be an
opportunity to deliver value for shareholders in line with that commitment. As
part of these initiatives the board has invited offers for the entire issued
share capital of the Company.
In recent months, detailed discussions have been held with a number of parties
but none has resulted in a definite proposal which the board could recommend
to shareholders. Accordingly, the board has resolved to look for opportunities
to develop the business further into areas, offering prospects of enhanced
returns, which also build on the Company's existing resources and skills as
well as lessening the Company's traditional dependence on the non-food retail
sector. In pursuing this objective the board has identified McIntosh.
McIntosh, based near Havelock Europa's headquarters in Fife, is the UK market
leader in the design, manufacture and installation of educational science
laboratories. Government expenditure in the education sector has increased
dramatically recently and the directors believe that high levels of demand are
likely to continue for some time as a result of many years of underinvestment
and the Government's commitment to correct this. McIntosh has been
particularly successful in securing the majority of work available in
educational PFI contracts in Scotland. Scotland's experience of PFI in terms
of improving the quality of school environments is greater than that of
England where the development of PFI is less advanced in this sector. The
directors believe that McIntosh is well-placed to benefit from the significant
new business opportunities which are emerging in the English market.
The terms of the acquisition are as follows:
(i) An initial payment of £3 million payable on completion to be
satisfied by the issue of 2,800,000 new ordinary shares in Havelock
Europa and approximately £2.1 million of loan notes (see (iv) below), subject
to a possible net asset value adjustment.
(ii) A first deferred payment based on McIntosh's audited
profit before tax (as defined in the share acquisition agreement) for the year
ending 31st December 2001 which, if payable, will be satisfied by the issue of
further loan notes. The maximum payment would be £2.5 million which would
require a profit before tax of £3 million. To the extent that such profit
falls below £3 million down to a profit of £2.5 million the first deferred
consideration will be reduced on a £ for £ basis and will reduce by £2 for
every £1 shortfall in profit below £2.5 million. No first deferred
consideration will be payable unless profit before tax exceeds £1.5 million.
Any amount payable in excess of £2 million relating to the first deferred
consideration will be placed in escrow pending agreement of the audited profit
before tax for the year to 31st December 2002 and its release will depend on
the average level of profit in that year and 2001 being not less than £2
million. The escrow amount, if it becomes payable to the vendors, will fund
the issue of further loan notes to them (see (iv) below). If the average
profits are less than £2 million the escrow amount will be released to the
(iii) A second deferred payment of up to £2.5 million, satisfied by the
issue of loan notes (see (iv) below), based on the audited profit before tax
for the year ending 31st December 2002 on the same formula as in (ii) above.
(iv) two individuals, who each own one share in McIntosh (out of a total
of 111), will receive cash as consideration rather than loan notes.
The maximum consideration payable is therefore £8 million; this amount will
only be payable if McIntosh's profit before tax (as defined in the share
acquisition agreement) in both 2001 and 2002 is at least £3 million.
The loan notes to be issued as part of the transaction will be guaranteed by
Bank of Scotland and will bear interest at one per cent. below Bank of
Scotland base rate. The loan notes may be redeemed at the vendors' option on
14 days' notice at any time at least six months and one day after the date on
which the relevant notes are issued, and will in any event be repaid on 31st
December 2004. The loan notes will not be listed on any exchange.
Other than the Consideration Shares referred to above, the acquisition will be
financed by a combination of existing and additional bank facilities.
The Consideration Shares are being issued at a price of 31.5 pence each being
the average closing mid-market price of the Company's shares according to the
Daily Official List on the five business days prior to signature of the Sale &
Purchase Agreement and will represent an increase of 9.99 per cent. in
Havelock Europa's issued share capital.
Application will be made to the UK Listing Authority for the Consideration
Shares to be admitted to the Official List. Application will also be made to
the London Stock Exchange for the Consideration Shares to be admitted to
trading. It is expected that listing of the Consideration Shares will become
effective and that trading in such shares on the London Stock Exchange will
commence on 25 September 2001. The Consideration Shares will, when allotted
and finally paid, rank equally in all respects with existing shares. The
Consideration Shares may be held in either certificated or uncertificated
form. No application has been made or is proposed to be made for the
admission of the Company's shares to trading on any other exchange.
FINANCIAL RECORD OF McINTOSH
The figures set out in this paragraph are extracted from the audited accounts
of McIntosh.
In the year ended 31st December 2000, McIntosh recorded an audited profit
before taxation of £931,709 on turnover of £13,316,363. At 31st December 2000
McIntosh's net assets were £3,854,593 and net debt (overdrafts, bank loans and
finance leases less cash in hand) was £886,757.
McIntosh's trading results in the seven months ended July 2001 have been
significantly ahead of the equivalent period of the previous year. An interim
dividend payment of £351,000 was made in July 2001. McIntosh intends, prior to
the completion of the transaction, to pay a dividend of £2,649,000.
MANAGEMENT OF McINTOSH
McIntosh's executive chairman is Roy Bell (age 60) who, through trusts
associated with his family and with other members of his family, presently
owns approximately 90 per cent. of McIntosh's share capital. McIntosh's
managing director is William McColl (age 43) who, through trusts associated
with his family, presently owns approximately 10 per cent. of McIntosh's share
Following the acquisition Messrs Bell and McColl will remain with McIntosh
reporting to Hew Balfour, chief executive of Havelock Europa. Havelock Europa
has given undertakings that McIntosh will operate as an autonomous business at
least until 31st December 2002.
Mr Bell will enter into a new fixed term service contract with McIntosh as
joint chairman expiring on 31st March 2003 under which he will work at
McIntosh at such times as may be required from time to time. Mr Bell has
indicated that it is his intention to retire when his contract expires.
Mr McColl will enter into a new service contract with McIntosh as managing
director terminable by three months' notice by either party, such notice not
to expire on or before 31st March 2003. Mr McColl will devote his full time to
the McIntosh business.
The directors believe that the acquisition of McIntosh will have the following
key benefits:
* a significant uplift in earnings per share compared with earnings per
share without McIntosh;
* a marked improvement in interest cover coupled with an enhanced
* the entry of the Group into a market where there is the opportunity for
significant growth and attractive returns and in which McIntosh has
already established a strong foothold;
* the integration into the Group of a business which is geographically
close to Havelock Europa's headquarters, involving similar production
processes to those used by Havelock Europa and where the Group's
established manufacturing skills can be brought to bear to support growth
and enhance profit;
* the opportunity to increase the efficiency of the combined business
through significant asset rationalisation; and
* a more even manufacturing work flow, as a result of the seasonal demand
for McIntosh's products falling earlier in the year than that of Havelock
Europa, thereby enabling an improved utilisation of the manufacturing
resources of the Enlarged Group.
A circular shortly to be posted to shareholders will contain a notice
convening an Extraordinary General Meeting of the Company for 24 September
2001 at which meeting an ordinary resolution will be proposed to approve the
Acquisition. Three further resolutions will be proposed to restore the
unissued share capital and the board's authority to issue shares to normal
levels, after taking account of the shares to be issued to acquire McIntosh,
as well as increasing the Company's borrowing powers.
for the six months ended 30 June 2001
As indicated in the Chairman's Statement at the AGM on 29 June the Group has
had a mixed start to the year, with a strong performance from Showcard Print
and the Middle Eastern joint venture and a more difficult trading environment
for the UK Retail Interiors Division.
The Group recorded a loss of before tax of £1,493,000 (2000 loss before tax :
£1,413,000) on a turnover of £24.3 million (2000 : £25.7 million), in what is
traditionally the much weaker half of the year.
The Board has declared an interim dividend per share of 0.5p (2000 interim
0.5p) which will be paid on 28 December 2001 to shareholders on the register
at close of business on 16 November 2001.
Retail Interiors
Turnover was sharply down at £11.4 million (2000 : £14.1 million) reflecting
difficult trading conditions in the retail fashion industry and a significant
reduction in the volume of work done for Marks & Spencer.
Point of Sale Display
Turnover increased to £10.2 million (2000 : £10.1 million) as a result of
increased penetration of the supermarket sector with Safeway becoming a more
significant customer offsetting a reduction with Arcadia. Volumes of business
with BHS also grew strongly.
Joint Venture
The joint venture made an excellent start to the year with a particularly
strong performance in the retail market. The business continues to generate a
substantial cash flow and during May repaid all outstanding indebtedness to
the Group.
Net debt at £10.8 million at 30 June 2001 compares with £15.1 million a year
earlier reflecting strong cash flows over the last 12 months and lower
interest charges. Gearing at 124.6% (2000 : 221.5%) is correspondingly lower.
The level of activity in the Retail Interiors Division is likely to be
substantially less than in 2000 and, with difficult and volatile conditions
persisting, it is too early to predict the outcome for this year with
certainty. However, lower volumes of business in Retail Interiors are likely
to be partly offset by a strong recovery at Showcard Print and a much
increased contribution from the Middle East, where prospects are most
Michael Kennedy 7 September 2001
For the six months ended 30 June 2001
Half Half Audited
Year Year year
Ended Ended Ended
30 June 30 June 31 Dec
2001 2000 2000
Notes £000 £000 £000
Group and share of Joint Venture 24,260 25,689 71,511
Less: share of Joint Venture's turnover (2,657) (1,302) (3,364)
-------- -------- --------
21,603 24,387 68,147
===== ===== =====
Operating (loss)/profit (1,461) (933) 2,266
Share of Joint Venture's
operating profit 373 64 408
-------- -------- --------
(1,088) (869) 2,674
Interest payable less receivable
Group (397) (521) (1,127)
Joint Venture (8) (23) (34)
-------- -------- --------
(Loss)/profit on ordinary activities before
taxation (1,493) (1,413) 1,513
Tax credit/(charge) on (loss)/profit on ordinary
activities 3 669 538 (412)
-------- -------- --------
(Loss)/profit for the period (824) (875) 1,101
Dividend (140) (140) (490)
-------- -------- --------
Retained (loss)/profit for the period (964) (1,015) 611
===== ===== =====
Basic and diluted (loss)/earnings per share 4 (3.0p) (3.1p) 4.0p
===== ===== =====
Dividend per share 0.50p 0.50p 1.75p
===== ===== =====
(Loss)/profit for the period (824) (875) 1,101
Exchange gain on investment in Joint Venture
16 16 19
Surplus on revaluation of fixed assets - - 1,125
______ ______ ______
Total recognised (losses)/gains relating to the
period (808) (859) 2,245
===== ===== =====
As at 30 June 2001
30 June 30 June 31 Dec
2001 2000 2000
Notes £000 £000 £000
Fixed Assets
Intangible asset - goodwill 135 173 154
Tangible assets 12,937 13,116 13,511
Investment in own shares 249 120 221
Investment in Joint Venture
- goodwill 148 172 160
- share of assets 2,075 1,077 1,503
- share of liabilities (1,254) (787) (877)
969 462 786
-------- -------- --------
14,290 13,871 14,672
===== ===== =====
Current Assets
Stocks 5 5,802 7,122 4,835
Debtors 6 10,755 11,000 14,729
Cash at bank and in hand 965 33 2,417
-------- -------- --------
17,522 18,155 21,981
Creditors - amounts falling due within one
year 7 (12,409) (13,989) (16,109)
-------- -------- --------
Net Current Assets 5,113 4,166 5,872
-------- -------- --------
Total Assets Less Current Liabilities 19,403 18,037 20,544
Creditors - amounts falling due after more
than one year 8 (10,195) (10,589) (10,388)
Provision for liabilities and charges (564) (610) (564)
-------- -------- --------
Net Assets 8,644 6,838 9,592
===== ===== =====
Capital and Reserves
Share capital 2,803 2,803 2,803
Share premium account 9 242 242 242
Revaluation reserves 9 1,762 637 1,762
Profit and loss account 9 3,837 3,156 4,785
-------- -------- --------
Equity Shareholders' Funds 8,644 6,838 9,592
===== ===== =====
For the six months ended 30 June 2001
Half Half Audited
Year Year year
Ended Ended ended
30 June 30 June 31 Dec
2001 2000 2000
Notes £000 £000 £000
Cash (outflow)/inflow from operating activities 10(a) (166) (314) 6,946
-------- -------- -------
Return on investments and servicing of finance
Interest received 29 2 16
Interest paid (448) (456) (1,078)
-------- -------- --------
(419) (454) (1,062)
-------- -------- --------
Taxation (212) (171) (442)
-------- -------- --------
Capital expenditure and financial investment
Purchases of tangible fixed assets (552) (614) (988)
Proceeds from sale of tangible fixed assets 32 - 49
-------- -------- --------
(520) (614) (939)
--------- -------- --------
Repayment of Loan from Joint Venture 186 - -
---------- ------- --------
Equity dividends paid - - (420)
-------- -------- --------
Cash (outflow)/inflow before use of liquid
resources and financing (1,131) (1,553) 4,083
--------- --------- --------
Financing and management of liquid resources
Repayment of loan notes issued on acquisition of
subsidiaries (100) (95) (115)
Loan to ESOP Trust (28) (120) (221)
Capital element of finance lease rental payments (193) (175) (358)
------- ------- -------
(321) (390) (694)
------- -------- --------
(Decrease)/increase in cash for the period. 10(b) (1,452) (1,943) 3,389
------- ------- -------
1. The figures for the financial year ended 31 December 2000 are
extracted from the statutory accounts for that year on which an unqualified
report was made by the Auditors and which have been delivered to the Registrar
of Companies. The summarised results for the half-year to 30 June 2001 and
the comparative results for the half-year to 30 June 2000 are non-statutory
accounts within the meaning of section 240 of the Companies Act 1985.
2. All operations are continuing.
3. A credit for taxation has been included at 36% (2000:37%), being the
effective rate likely to be applied to the UK result for the full year to 31
December 2001. The results of the Middle East joint venture are not estimated
to be subject to taxation in this year.
4. (Loss)/earnings per share is calculated by dividing the loss or
profit after tax by 27,443,429 (2000: 28,033,849) being the average number of
shares in issue during the period, excluding those held by the employee share
scheme in accordance with UITF 13. There is no dilutive effect of unexercised
share options.
5. Stocks 30 June 30 June 31 Dec
2001 2000 2000
£000 £000 £000
Raw material and consumables 1,926 2,182 1,588
Work in progress 1,710 2,248 1,082
Less: payments to account (26) (15) -
Finished goods 2,192 2,707 2,165
--------- -------- --------
5,802 7,122 4,835
===== ===== =====
30 June 30 June 31 Dec
2001 2000 2000
£000 £000 £000
6. Debtors
Trade debtors 9,133 9,338 13,671
Other debtors 744 530 348
Prepayments 878 1,132 710
-------- -------- --------
10,755 11,000 14,729
===== ===== =====
7. Creditors: amounts falling due within one year
30 June 30 June 31 Dec
2001 2000 2000
£000 £000 £000
Bank advances (secured) - 2,948 -
Loan notes 1,144 1,264 1,244
Trade creditors 6,539 5,501 8,281
Corporation tax - - 359
Other taxes and social security 1,008 879 2,943
Accruals 2,835 2,602 2,539
- Final 350 280 350
- Interim 140 140 -
Obligations under finance leases 393 375 393
-------- -------- --------
12,409 13,989 16,109
===== ===== =====
The loan notes are repayable at par on the holder giving one month's
notice. In so far as the notes have not already been redeemed, they will be
redeemed in full by the Company on 5 January 2003 at par.
8. Creditors: amounts falling due after more than one year
30 June 30 June 31 Dec
2001 2000 2000
£000 £000 £000
Bank loans (secured) 10,000 10,000 10,000
Obligations under finance leases 195 589 388
-------- -------- --------
10,195 10,589 10,388
===== ===== =====
9. Reserves
Share Revaluation and Loss
Premium Reserve Account
£000 £000 £000
At 1 January 2001 242 1,762 4,785
Exchange gain on investment - - 16
Loss for the period - - (964)
------- ------- -------
At 30 June 2001 242 1,762 3,837
==== ==== ====
10. Cash Flow Statement Half Half
year Year Audited
ended Ended Year
30 30 Ended
June June 31 Dec
2001 2000 2000
£000 £000 £000
a) Reconciliation of operating (loss)/profit to net
cash flow from operating activities
Operating (loss)/profit (1,461) (933) 2,266
Depreciation and amortisation charges 1,049 1,073 2,166
Loss on disposal of fixed tangible assets - - 10
(Increase)/decrease in stocks (968) (518) 1,769
Decrease/ (increase) in debtors 4,496 3,765 (330)
(Decrease)/increase in creditors (3,282) (3,701) 1,065
------- ------- -------
Net cash (outflow)/inflow from operating activities (166) (314) 6,946
------- ------- -------
b) Reconciliation of net cash flow to movement in net
(Decrease)/Increase in cash for the period (1,452) (1,943) 3,389
Finance lease payments 193 175 358
Loan notes redeemed 100 95 115
------- ------- -------
Movement in net debt in the period (1,159) (1,673) 3,862
Opening net debt (9,608)(13,470)(13,470)
-------- -------- -------
Closing net debt (10,767) (15,143)(9,608)
===== ===== =====
c) Analysis of net funds
At Other At
1 Jan Cash non-cash 30 June
2001 flow changes 2001
£000 £000 £000 £000
Cash at bank and in hand 2,417 (1,452) - 965
==== ==== ==== ====
Debt due within one year
Loan notes (1,244) 100 - (1,144)
Finance lease creditor (393) 193 (193) (393)
------- ------- ------- -------
(1,637) 293 (193) (1,537)
------- ------- ------- -------
Debt due after one year
Bank loans (10,000) - - (10,000)
Finance lease creditor (388) - 193 (195)
------- ------- ------- -------
(10,388) - 193 (10,195)
------- ------- ------- -------
Total net debt (9,608) (1,159) - (10,767)
===== ==== ==== =====
11. The interim statement for the six months ended 30 June 2001 was approved
by the Directors on 6 September 2001.
KPMG Audit Plc
24 Blythswood Square
United Kingdom
We have been instructed by the Company to review the financial information set
out in Part 3 of the circular dated 7 September and we have read the other
information contained in the interim report and considered whether it contains
any apparent misstatements or material inconsistencies with the financial
Directors' responsibilities
The interim report, including the financial information contained therein, is
the responsibility of, and has been approved by, the directors. The Listing
Rules of the Financial Services Authority require that the accounting policies
and presentation applied to the interim figures should be consistent with
those applied in preparing the preceding annual accounts except where they are
to be changed in the next annual accounts in which case any changes, and the
reasons for them, are to be disclosed.
Review work performed
We conducted our review in accordance with guidance contained in Bulletin 1999
/4: Review of Interim Financial Information issued by the Auditing Practices
Board. A review consists principally of making enquiries of group management
and applying analytical procedures to the financial information and underlying
financial data and, based thereon, assessing whether the accounting policies
and presentation have been consistently applied unless otherwise disclosed. A
review is substantially less in scope than an audit performed in accordance
with Auditing Standards and therefore provides a lower level of assurance than
an audit. Accordingly, we do not express an audit opinion on the financial
Review conclusion
On the basis of our review we are not aware of any material modifications that
should be made to the financial information as presented for the six months
ended 30 June 2001.
KPMG Audit Plc
Chartered Accountants
7 September 2001
*All intraday prices are subject to a delay of fifteen (15) minutes.
FE Investegate takes no responsibility for the accuracy of the information within
this site.
The announcements are supplied by the denoted source. Queries about the content
of an announcement should be directed to the source. FE Investegate reserves the
right to publish a filtered set of announcements. NAV, EMM/EPT, Rule 8 and FRN Variable
Rate Fix announcements are filtered from this site.
2017 Financial Express. All rights reserved. Visit other
FE websites
Go to website
FE Trustnet UK
FE Trustnet Offshore
FE Trustnet Hong Kong
FE Trustnet Middle East
FE Analytics
FE Fundlistings
To continue using FE Investegate, please confirm that you are a private investor.
*A Private Investor is a recipient of the information who meets all of the conditions set out below, the recipient:
1. Obtains access to the information in a personal capacity;
2. Is not required to be regulated or supervised by a body concerned with the regulation or supervision of investment or financial services;
3. Is not currently registered or qualified as a professional securities trader or investment adviser with any national or state exchange, regulatory authority, professional association or recognised professional body;
4. Does not currently act in any capacity as an investment adviser, whether or not they have at some time been qualified to do so;
5. Uses the information solely in relation to the management of their personal funds and not as a trader to the public or for the investment of corporate funds;
6. Does not distribute, republish or otherwise provide any information or derived works to any third party in any manner or use or process information or derived works for any commercial purposes.
This website is only for private investors. By using this site, you agree to use the content for private use only.
Please confirm that you are a private investor using the buttons below.


text:
Kristen Bell's character takes a stroll down memory lane, recounting her life as a high school detective.
The first two minutes of "Veronica Mars" movie arrives online, two weeks before it hits theaters across the country. It features a voiceover from Kristen Bell's character as she recounts her life back in her hometown of Neptune while she was in high school.
"A teenaged private eye. Trust me, I know how dumb that sounds," she says as footage from the original TV series plays. "But it's not like I found a decoder at the bottom of a cereal box and thought, 'That sounds like fun.' I wish. That would have been adorable."
The former high school detective now has a new life in the Big Apple. She is on her way to become a high-powered New York attorney and is living a happy life with her new beau Piz, but an unexpected call forces her to come back home and meet her old friends & enemies.
Jason Dohring returns as Veronica's ex, while Chris Lowell plays her new beau. One of the most successful Kickstarter projects with $5.7 million collected from the online fundraising, the adaptation of neo-noir mystery drama series of the same name is set to make its way out in the United States on March 14.

subset: commoncrawl


text:
Recent diary entries
bus stopsPosted by Polyglot on 17 August 2017 in English (English)
Over the past few years, I've been mapping a lot of bus stops and routes. Over the past few months I've been looking around how it's done in other places around the world.
What I find (this may of course be influenced by what I wanted to find) is that most bus stops start out as a node next to the way, tagged highway=bus_stop, usually with a name on it.
Then somebody comes along, who glues it to the way. Then somebody else comes along who maps a platform next to the way, using a way, copying all the tags over. They do this regardless of the whether a platform actually exists. They think they need this to add 2 objects per stop to the route relations. Somehow the wiki convinces them of the need for this.
Mapping platforms as ways where there aren't actual platforms feels wrong to me. Adding a set of details to more than one object also doesn't feel like the most sensible thing to do. Adding 2 objects to each route relation for 1 real life object makes working with these route relations harder to do.
I'd like to see that a casual mapper can start out mapping a bus stop as a node next to the way, as highway=bus_stop.
Possibly they add public_transport=platform to this node. It seems odd to do so, even if no platform is there, but that's how things evolved. Tagging it as public_transport=platform means that a role platform will be assigned to it in the route relation. (if the route relation has public_transpot:version=2). It's the answer I got when I asked the question a few years back on the mailing list. I usually put that node more or less where the pole is. But the exact position is not all that important, as long as it's more or less where passengers will be waiting.
As far as I'm concerned this node is what represents the bus stop at this side of the street, so it seems obvious that this is the node that should be added to the route relations. The nice thing about doing it that way, is that there is no need to transfer details or relation membership from one object to another. This node is there for the lifetime of the stop. One object to work with, containing all the details, including directly available coordinates.
Now the stop_position nodes. First off, I don't see a need to map all of them and since where I map bus lines they are not all present, I don't see why we would add any of them to the route relations. No need to repeat the stop's details on them either.
Then the platform ways. If there are actual platforms, I would tag them highway=platform/public_transport=platform. Nothing more, nothing less. No need to add them to the route relations.
Then the stop_area relations. This is where we get the chance to indicate which platform node(s) belongs to which stop_position node(s) (if mapped) and which platform way (if present). Doing it this way means to have such relations for each group, where a group is the ones on one side of the road or the ones belonging to 1 platform in a bus station. They can then be grouped in a hierarchy of stop_area_group relations, although this is only needed for the more complex ones and for bus stations.
Sometimes I wonder if I should create a proposal for this. Usually I give up before even getting started, as I know how hard it is to convince anyone in the OpenStreetMap universe, once they are set in their ways. Little by little I'm starting to build the courage to go ahead with it after all. Writing these diary entries is a small first step, also to see if there would be support for such a simpler way of mapping public transport.
Also don't get me wrong, it's still possible to fill in all the detail of the accomodation surrounding the bus stops, but in a way that builds further on what was mapped previously, instead of converting from one object type to another or needing to add details more than once.
Public Transport Mapping, why do we add the stop details several times over?Posted by Polyglot on 27 July 2017 in English (English)
When we started mapping public transport stops, some people insisted on mapping them on nodes next to the way, others thought the right way to do it, was to add them as nodes being part of the highway, thereby losing the information on which side of the road the bus stop was.
Then somebody came by with the idea to unite both ways of mapping. In itself that sounds great. But where do we add the details then? On both? That doesn't really make sense. It's a maintenance nightmare.
So we still have some people adding the stops as stop_position nodes on the highways and others mapping them as isolated nodes next the ways as public_transport=platform. But of course a node is not a platform, so others map those as ways and areas. Nothing wrong with that, but why do we need to add all the details to these ways?
For some reason it was decided that both these stop_postion nodes and the platform ways/nodes need to be added over and over again to the route relations. These route relations represent each and every variation of the public transport lines, so there are thousands of them. Another maintenance nightmare.
Why can't we have a node next to the way, with all the relevant details and add those nodes to the route relations, then followed by a continuous string of ways? The node gets tagged public_transport=platform/highway=bus_stop.
The node isn't always representing an actual platform. If there is a platform, nothing wrong with representing it as a way or an area. But there is no real need to duplicate all the details like name/ref/route_ref/zone to these ways. And there isn't really a need to add them to the route relations.
For the simplest bus stops a node next to the way public_transport=platform/highway=bus_stop is all that is needed. It contains all the relevant information and it has coordinates, which makes it convenient to compare it to data from operators.
For more completely mapped bus stops, benches and waste_baskets can be added.
If you want to make explcit where the vehicle stops, a public_transport=stop_position can be added on the highway. For the first and last stops, the way should be split there, as it's the beginning or end of the route.
But these stop_position nodes are not all that important, so no real need to map them for every stop. Also no reason why the stop details should be repeated on them and no real need to add them to the route relations. It's enough to add them to stop_area relations.
Public Transport PluginPosted by Polyglot on 1 July 2016 in English (English)
Mapping public transport routes on OpenStreetMap can be a challenge, keeping them correct and up-to-date even more so. Last year I mentored the Mapillary plugin for GSoC. Before that, I had been working on public transport a lot, and to add the stops precisely where the poles are, horizontal imagery is a big help, when it's available. The idea to propose a GSoC project for public transport this year was a logical consequence of some Python scripting I had started on. It's possible to run Python in JOSM, but it involves too much setup for it to be practical for general use by other mappers.
Still, automation is key. Without it, it's next to impossible to even find all the problems with the route relations, let alone fix them.
Also the way we're mapping public transport, at the moment (who knows one day route segments become the thing), is very repetitive and fixing all those routes for all variations of the lines gets tedious fast. This in turn results in very few people interested in doing it. And the ones that do burn out sooner or later.
I'm sure the new plugin will be a big help to solve that problem.
At the moment the plugin is very good at detecting problems with the routes:
- going against oneway traffic
- gaps that are caused by wrongly ordered ways (automatic fix available)
- routes that don't start/end on a stop_position node
- ways that still need to be split on those terminal nodes
- buses or trams that travel over ways unsuitable for that mode of transport
The latest addition is a dedicated extra layer. This layer highlights the route for which a relation editor window is open. You can have several relation editor windows open, but only the last one that had focus, will be shown highlighted. One thing that I was never able to achieve with plain MapCSS is to show sequence numbers for the stops and the platforms. The other was showing the refs of all the route relations serving those stops. All that becomes trivial (compared to MapCSS) if one can code it in JAVA, and Darya is doing a great job there.
So, what's next?
The initial idea was to be able to start from a route relation containing just stops in the correct order and have the code figure out which ways to add to the relations. That will still happen, but fixing existing route relations and helping all mappers to keep the route relations 'coherent', when they make changes to the underlying highway/railway infrastructure is a higher priority, so we started by integrating the plugin in the validator. Thus making it very accessible for anybody who installs the plugin. It's amazing how many problems have already been able to solved - both in the routes and in the ways they followm, as in the platforms and stop_positions -during beta testing of the code.
Want to try it yourself?
You can easily install the PT_assistant plugin in JOSM and help with testing.
User documentation can be found here
What I usually do, is File / Download from Overpass API (expert mode needs to be on for it to show that option in the menu, don't ask me why) Then use the following query:
out meta;
You can select routes for other modes of transport, of course. After downloading, I make sure nothing is selected, then press the validate button. I usually use the last option, as I don't want all the fixes applied automatically for the time being. Implementing automatic fixes with user intervention where there is doubt, is in the pipeline. If you have the plugin installed, you'll find several categories that start with PT_
The easiest ones to tackle are: * Route contains a gap that can be fixed by sorting
For those you can simply press the fix button. Don't select more than, say 5, at a time.
If your stops where not at the beginning of the route, now they will be. The order should be preserved. If they don't have roles, select all of them, make them selected in the editor window, remove them from the Relation Editor and readd them. Now go visit the ones that still don't have roles and fix their tagging.
Now press the upload button, which will result in a new validation Usually you'll find there are more problems to solve at this point. For the routes that have ways going against oneway traffic, pressing the fix button will result in removal of that way. It's better to press right mouse button Zoom to problem, select the way(s) that have a yellow casing around them, then press right mouse button edit. The relation editor will open with those ways selected in blue. Now it's possible to remove them, or to add oneway:bus=no, if that is the proper solution. If you remove them, you probably want to readd ways from the other side of the dual carriageway or roundabout. If you notice that there are several variations, which are likely to need the same fix, keep the 'problem ways' selected and open all of them in relation editor windows. After all are openedm select the ways to replace them with, and do this in each editor window.
Be careful not to split ways for which you have relation editor windows open.
You'll get 'conflicted with yourself', which is something to avoid at all cost :-)
Have a look in the comments to learn how to avoid conflicts while keeping RE windows opened.
All this may seem like it's still a lot of manual work and you're right, it is. The intention is to automate all this further. I'll probably write a new diary entry in a few weeks about that.
If you're interested in a hangout about the mapping of public transport and the use of the plugin, get in touch and we'll set one up.
Setting up JOSMPosted by Polyglot on 13 January 2016 in English (English)
I recently configured OBS (Open Broadcast Software) to conveniently make screencasts toward Twitch.tv.
Usually I use this to show HOT contributors what I did while validating their tasks/tiles. I get some nice response to this. People like the feedback and the tips. I think it works as a motivator to keep going as well.
For the past few weeks I had this plan to create more to the point video material to show how to map with JOSM and why I think it's so much more convenient and efficient to do so.
I had a problem with Bing imagery that was solved, by dumping my profile, so I seized the opportunity to show to get started with JOSM. While doing this I noticed there was imagery for Svalbard available and WOW, that is great imagery! So went on to improve my mapping of the Global Seed Vault. The video shows how to improve way accuracy, how to make nice bends in the roads, how to draw buildings very accurately, how to link to Wikipedia and Wikidata. How to jump to these articles in your web browser from withing JOSM and so much more. As usual I went a bit overboard, sorry about that.
I did it once more, this time with sound: Setting up JOSM for HOT mapping
These have no sound:
Cooperation between free content projects: how to link from Wikipedia to OSMPosted by Polyglot on 14 August 2015 in English (English)
This blog entry describes how and why the following module was developed:
In the mean time I added extensive documentation to it, which might be more interesting than what I wrote here... so go and have a look!
With the advent of Wikidata my interest in Wikipedia flared uponce more. I'm a mapper for Openstreetmap in the first place, but last year I already made a little sidestep to Wikivoyage. That's a project which is closer in many ways to Openstreetmap than Wikipedia.
Recently I started adding wikidata tags to streets and other objects in Openstreetmap. Which in itself doesn't do all that much. So a way is needed to make this available to the rest of the world. Wikipedia seems like the way to accomplish this.
I had already experimented a bit with links to saved queries on Overpass Turbo. But creating these queries from scratch over and over again and creating such links to them, isn't the most straightforward way to get things done.
When it became clear to me that sometimes an additional query of wikidata may be necessary, before invoking Overpass, I knew I had to tackle the problem in another way.
This made me look into Lua, the scripting language which was chosen to automate the plethora of MediaWiki projects. After one day I came up with a working script (in the mean time it's been developed quite a bit further):
On the Dutch Wikipedia reception was luke warm. I'm afraid, I hadn't been able to carry across what I was trying to achieve. On the English Wikipedia a Lua developer saw the potential and he helped me to improve the code and explained me how to go about adding test cases. This helps a lot to not introduce bugs while attempting to add new features. For the case of querying several Q-numbers at once using a regex query, help came from a specialist in Overpass.
So this saved query:
now looks like this in the article:
{{#invoke:OSM|etym|display=Streets named after Leuven|timeout=50|query=[highway]|coord=50.879;4.701;9}}
which results in the following query:
[timeout:50][out:json]; ( node["name:etymology:wikidata"="Q118958"][highway]({{bbox}}); // remove the ({{bbox}}) if you want the query to be executed globally way["name:etymology:wikidata"="Q118958"][highway]({{bbox}}); relation["name:etymology:wikidata"="Q118958"][highway]({{bbox}}); ); out geom;
The difference with the stored query is that only streets closer to Leuven are fetched. If the user wishes to do so they can either remove the ({{bbox}}) statements or they can move the map to another region and press Run. In case the user also wants to see other objects named after Leuven, they can remove the [highway] part.
Now, let's hope the Wikipedia contributors at large see value in this. I deployed it on the French Wikipedia as well and will probably continue with Spanish, German and Esperanto. Feel free to deploy it on other language versions as well. I will keep all the modules in sync. I'm only going to develop test cases on the English Wikipedia, so that will be the primary place to continue development. One test is failing because of lack of arbitrary access, but that should be resolved shortly.
Actually there is a whole plethora of possibilities:
- objects named after the subject of the Wikipedia article (on condition they got name:etymology:wikidata tags on the OSM side)
- the object of the article itself (on condition they got wikidata tags on the OSM side)
- other objects related to the article (this is probably not OK with Wikipedia policies)
- objects of which the subject of the article is the architect or the artist who created them (architect and artist.wikidata)
- objects related directly to the subject (subject.wikidata), this can be tombstones as well
- objects carrying brand:wikidata or operator:wikidata tags
- relations representing public transport lines. The names of the stops are emphasized with help of MapCSS styles
Samenwerking tussen open content-projectenPosted by Polyglot on 4 August 2015 in Dutch (Nederlands)
Met de komst van Wikidata is mijn interesse in Wikipedia weer wat opgeflakkerd. Ik ben in de eerste plaats een mapper voor Openstreetmap, maar vorig jaar heb 'k ook al 's een zijsprongetje gemaakt naar Wikivoyage. Een project dat vrij goed aansluit bij Openstreetmap.
Nu ben ik recent begonnen met het voorzien van straten en andere objecten in Openstreetmap van wikidatatags. En aan welk project voor vrije content denkt een mens meteen, om ervoor te zorgen dat dat werk ook voor de rest van de wereld ter beschikking komt? Inderdaad: Wikipedia.
Ik had al wat geëxperimenteerd met links naar opgeslagen queries op Overpass Turbo. Maar heel handig is dat toch niet. Een query moeten aanmaken voor elk wikidata-item en elke nieuwe soort bevraging.
Daar komt dan nog bij, dat een Kerkstraat vernoemd naar een bepaalde kerk naar die specifieke kerk verwijst, maar als je alle Kerkstraten wilt terugvinden tesamen met alle 'Rue de l'Église', moet je eigenlijk eerst wikidata gaan bevragen. Maar dat zal nog niet voor direct zijn.
Het heeft me er wel toe aangezet om me 's in Lua te gaan verdiepen, de scriptingtaal gekozen voor de MediaWikiprojecten. Een dag later hebben we nu dus een script dat Overpass queries genereert:
Nu komen de Wikipediamedewerkers en ikzelf niet altijd zo goed overeen. Als ik buslijnen toevoeg, krijg 'k te horen dat ze geen busboekje willen zijn. 't Kost dus allemaal nogal wat moeite, want dan moet 'k op zoek naar bronnen en referenties over het ontstaan en de geschiedenis van zo'n route.
M'n test case werd alweer ongedaan gemaakt. Gelukkig is het mogelijk om naar een specifieke versie van een pagina te verwijzen:
Dus wel verloren voor het nageslacht, maar niet voor wie mijn hersenspinsels hier leest.
Ook op de pagina over Leuven had 'k al eerder een query gezet die alle straten die naar Leuven vernoemd zijn ophaalt.
Oorspronkelijk dus deze opgeslagen query:
Maar nu ziet het er als volgt uit (in het artikel):
{{#invoke:OSM|etym|linktext=Straten wereldwijd vernoemd naar Leuven, inzoombaar|query=[highway]|coord=50.879;4.701;9}}
wat resulteert in het volgende:
http://overpass-turbo.eu/?Q=( node["name:etymology:wikidata"="Q118958"][highway]({{bbox}}); // remove the ({{bbox}})if you want the query to be executed globally way["name:etymology:wikidata"="Q118958"][highway]({{bbox}}); relation["name:etymology:wikidata"="Q118958"][highway]({{bbox}}); ); out;
; out meta qt; &C=50.879;4.701;9&R
Het verschil is dat de query nu enkel straten ophaalt, die dichter in de nabijheid van Leuven liggen. Als de gebruiker dat wenst, kan hij/zij zelf de ({{bbox}})-statements weghalen. In het geval dat de gebruiker ook andere objecten wenst te zien, die naar Leuven werden vernoemd, dan volstaat het om [highway] te verwijderen.
Goed. De deur staat open om links te leggen van Wikipedia-artikelen naar OSM-objecten, iets wat we al langer in de andere richting doen. Nu is het echter de vraag of Wikipedia daar klaar voor is, of zelfs of het dat ooit zal (willen) zijn.
Veel meer dan de technische hulpmiddelen bieden, kan ik niet meer voor hen doen.
Mapillary 1.0 for AndroidPosted by Polyglot on 9 March 2015 in English (English)
Mapillary for Android was updated and I've been meaning to write about it here.
Blog entry by developer of the app
The app now has a big green hot-button, which is very practical to go into picture making mode quickly.
The app now allows automatic shooting of pictures every 2 seconds even when standing still (or walking/cycling, the intended usage). The way to make it pause is to point it downwards. It's not perfect at detecting this though, so I end up with quite a few pictures of my feet... It also stops shooting when you shake the phone too much. Maybe I should try that instead to pause it :-)
Oh, it's possible to pause manually as well, of course, but that has the side effect of starting a new sequence. Sometimes that's what you want, but not always.
It's possible to let the app upload as soon as it's in range of Wifi. That's practical, but I disabled that option in the mean time. I prefer to browse through my pictures on the larger screen of the portable, as it allows to weed out the bad ones more easily. The way to review pictures on the phone was improved, but it still feels like a lot a lot of finger movement and my phone doesn't seem to understand the 'long click' very well. I also lose track of which sequences I already reviewed and how far into them I had gotten, before having to context switch to irl.
Using the PC also has the advantage of the keyboard. On top of that, I can work with the pictures in the usual way of working with images in JOSM. Just load whatever GPX file, then use right mouse button on its name in the layer list to load pictures from the Mapillary folder on your phone's memory card. This works, because they are already geotagged. I do that while it's connected over the USB cable.
The advantage is that it's possible to review the pictures once more and you don't have to wait for the pictures to be processed.
After all that reviewing, I then release the pictures to Mapillary by enabling wifi and going into review mode.
Since I'm "multimodal", walking quite often, but also on the bicycle, I needed a way to secure the smartphone. I'm glad I finally found a use for 2 of those lanyards and a rubberband bracelet I've been receiving at conferences. I really should make a picture of that 'construct'.
The rubberband around the middle gets in the way when typing, so the next phone I get should come with a proper silicone protection jacket around it.
My findings are that pictures taken while cycling, while holding the phone in one hand, can be OK, but only with enough sunlight coming from behind. With the sun in front the pictures become dark and with insufficient light the shutter remains open longer, resulting in unsharp pictures.
The same is true to a lesser extent while walking. The sharpest pictures are those taken when standing still.
I'm not sure it they're very happy at Mapillary with my pictures, as I'm turning around a lot and focusing on those details that matter for adding details to Openstreetmap. I don't like switching back and forth to Panorama mode though. That new autoshooting walking mode is so convenient!
I'm sure glad Mapillary is around now, as it becomes possible to add context to the pictures of those details I'm interested in, by also making pictures of the surroundings and how one got there. At the end of the day, that's a lot of pictures though... but it opens possibilities we didn't have before. Like enabling other people to add the details to OSM that happen to be important to them.
1001-bomen-voor-LeuvenPosted by Polyglot on 5 March 2015 in Dutch (Nederlands)
Deze kaart laat toe om te zien hoeveel bomen en groenruimtes er zijn in Leuven. De data komt uit Openstreetmap.org.
Aan de linkerkant bovenaan kan u in/uitzoomen met de +/-, maar dat gaat eveneens met het muiswieltje.
Onder deze iconen staat een knop, waarmee u lagen kan selecteren. Klik eens op het oog van de heatmap-laag, om de 'concentratie' van de bomen te zien.
Dit is voorlopig niet echt representatief, aangezien niet elke boom al ingebracht werd in Openstreetmap. Wij hopen dat we dat wel kunnen realiseren met de hulp van de groendienst, de KU Leuven en u.
Voor sommige bomen werd species (soortnaam), genus en soms zelfs een foto toegevoegd. Als de foto op Mapillary.com staat, is het zelfs mogelijk om een virtueel bezoek aan die plaats te brengen. Dat wil zeggen dat er daar iemand is langsgeweest, die nog meer foto's gemaakt heeft van de omgeving van de boom.
U kan zelf bomen toevoegen aan de Openstreetmapdata. Klik op de knop More en dan de voorlaatste knop. Waarschijnlijk is het het eenvoudigste om daarvoor de iD-editor te gebruiken. Dan hoeft u geen extra software te installeren. Als u veel bomen wenst toe te voegen, geef ik graag een woordje uitleg over hoe dat efficiënt gedaan kan worden met JOSM.
U kan ook voorstellen formuleren, over waar er volgens u bomen of groenruimte kan worden toegevoegd. Daartoe kan u de knoppen aan de rechterkant gebruiken, nadat u op dat potloodje heeft geklikt om naar editeermodus te gaan.
Spijtig genoeg is het niet mogelijk om slechts bepaalde stukken van de kaart voor iedereen editeerbaar te maken. Het is alles of niets. Daarom is het nodig dat u eerst een account aanmaakt.
En deze dan hier toevoegt: http://umap.openstreetmap.fr/nl/ (Inloggen / Log in)
Als u me dan een boodschap stuurt, voeg ik u toe als bewerker voor de kaart.
Wat ook kan, is hier oefenen. Hier kan alles aangepast worden, maar de consequentie is dat ook alles gewist kan worden door eender wie...
U moet dan wel nog even laten weten, waar u iets heeft toegevoegd. Het is waarschijnlijk ook het beste om daar steeds op een eigen nieuwe laag voor aan te maken.
First Missing Maps in NL and MapillaryPosted by Polyglot on 15 February 2015 in English (English)
After participating in the Missing Maps in Antwerpen, I went to the one in The Netherlands yesterday. Big thanks to Philip for making this possible for me!
The people from MSF/AZG/DWB/Red Cross had 2 Tasks in mind for us.
A though one in Africa where we had to add natural wood and rivers, as those are the (breeding) habitat for tse-tse flies, which cause sleeping disease. The beginners using iD had to abandon that one, as it's impractical to zoom in far enough to work and still see the bigger picture. With JOSM one can draw a general contour of the wood at low zoom, then refine it by using the Improve Way Accuracy mode zoomed in a lot further. It's still a daunting task to get it right though. What can be considered wood/forest? How does one recognise wetlands?
The other task was in Haiti. It was not easy either. A densely populated area and MSF wants to know how many buildings there are. (It's explained better in the description...)
It peaked my interest for 2 reasons:
- They used a drone to create superior aerial imagery
- The Red Cross drove around with a smartphone used as a dashcam. The pictures were uploaded to Mapillary. Press that little play button and enjoy the ride.
This allows to go and have a look around and see what's actually there. The width and state of the road, the state of completion of the buildings and so on.
Coverage is more limited than what can be seen from above, but it's possible to read the name of a school and then it's clear as well that it is a school.
The great thing about Mapillary is that the barrier of entry to contribute yourself is a lot lower than say, fly a drone to create excellent imagery...
All you need is a smartphone with a descent camera and GPS. Bonus points if it has a electronic compass, but that information can also be gotten from the GPX track. (electronic bread crumbs trail of where you've been).
I've been doing this for Geofort, somewhat surprised that I was the first one to do it. We've also covered a good part of the way over to Geofort from Belgium. Interrupted between Brasschaat and Breda because of a drizzle.
Only It's so Funny did the same. I had expected to see all the roads to the geofort from all directions. Now I feel bad for not having mentioned it on the Meetup group beforehand. Mapillary still seems less known than I had expected. Hence this diary entry.
Let's give Google Streetview some competition and do them one better! There are so many places their survey cars can't reach! And hopefully one day, they decide to be even nicer than they claim to be and give us permission to look at their Streetview to improve Openstreetmap. One can always be optimistic :-)
Added most road signs to the Belgian data file now. Needs testing.Posted by Polyglot on 8 February 2015 in English (English)
In Finland they seem to think it's a good idea to also add the road signs themselves. I tend to agree with them, but trying to add them all, may not make sense, of course, as there are a gazillion of them.
There are no applications making use of this information, but for us it would enable double checking why some ways have certain tags.
In Finland they are also able to find where zones are 'leaking' and they report this back to the administrations, so it gets fixed.
So I'm not saying we should aim to map all of them, but I still want it to be possible and convenient to add those that have our interest.
So I've been working on the RoadSigns plugin to make sure it has data about the Belgian Road signs. The work is not done yet, but I think I was now able to add all the accompanying signs and all signs related to parking, of which there are surprisingly many! The way it works now, you'll have to remove the tags it adds, for those objects they don't apply to. I've made a few suggestions for improving the workflow, but it's unlikely those will be implemented anytime soon, except if I get my hands 'dirty' and do it myself...
So the effect of the sign remains on the ways, and the (Belgian) code for the sign itself remains on the new node you created before using the plugin.
If you don't check the tick box Traffic sign, that code won't be added and you don't have to remove any tags. The plugin then does what it was designed for, add the effect of the sign to the ways it applies to.
What I'm not sure of, since it was an enormous task that I gravely underestimated, is whether all the tags, that are applied as an effect are actually correct. So the plugin needs testing.
Or you can have a look at this wiki page, there may be obvious errors in it that jump out to you :-)
Using the plugin is a bit more convenient though, as you can actually see the signs, instead of those codes.
Oh, if you see that additional signs are missing from signs they can be next to, also report that please.
Extending the RoadSigns plugin, so it works for BelgiumPosted by Polyglot on 2 February 2015 in English (English)
While looking at source code of JOSM plugins, I stumbled across the RoadSigns and the ScoutSigns plugins. ScoutSigns adds some source data added by people using Skobbler.
For each sign, it gives a litlle picture taken by that 'reporter'. When adding the effect of those signs on the road it applies to, I was wondering if it would be possible to map the sign itself.
At the moment the RoadSigns plugin doesn't support that yet. But that's what an old hand like me needs it for. I know the tags which get applied to the way, mostly by heart by now. But those codes which are different from country to country, can't be bothered to remember those.
So I was thinking it might be nice to be able to add a node next to the way, select it and select the way(s) it affects. Then click on the little extra icon on the top right of the Tags pane. Select a traffic sign and signs that accompany it. Then it should automagically do the right thing with both the ways and that isolated node next to the way.
I think it's needed to extend the xml format. I created an example here:
Now I'll have to get my hands dirty and start coding to make that happen, so I can hand a patch to the developer of the plugin.
But before doing that, I also want it to work for Belgian signs.
To do that, we also need icons.
They are here: http://wiki.openstreetmap.org/wiki/Road_signs_in_Belgium
Fortunately they are also on the German Wikipedia. I fetched all the SVG files as follows:
import wikipedia
import urllib.request
import re
filenameRE = re.compile(r'http://upload.wikimedia.org/wikipedia/commons/.+/.+/Belgian_road_sign_(\w\d+(\w)*.svg)')
wp = wikipedia.page("Bildtafel_der_Verkehrszeichen_in_Belgien")
print (dir(wp))
for url in wp.images:
fn = filenameRE.match(url)
if fn: fn = fn.group(1)
print (url)
print (fn)
if fn: urllib.request.urlretrieve(url, fn)
Before that "import wikipedia" line works, you'll have to do pip install wikipedia where you installed Python
For the next part, of converting those SVG files to PNG, I tried to use Powershell, as I need to learn how to work with, but the syntax is horrid and I got disgusted.
So back to my trusted Python:
from glob import glob
import subprocess
for fn in glob('C:\data\RoadSigns\*.svg'):
bn = fn.split('.')[0].split('\\')[-1]
print (bn)
print(subprocess.check_output(['C:\data\Program Files (x86)\Inkscape\inkscape.exe', '-z', '-h 40', bn + '.svg', '-e ' + bn + '.png'], shell=True))
I took a while to figure all that out and get the syntax right, hopefully it's useful for somebody else, some day.
Mapillary in iDPosted by Polyglot on 29 January 2015 in English (English)
I went totally out of my comfort zone today. I was reviewing some pictures I had submitted to Mapillary and found one, I wanted to add right away to OSM. So I tried the link to edit it with iD. The first thing that's odd, is that the zoom level is far out and the location of the object is way off. (It ends up all the way to the right, under the vertical button bar). I'd have expected it to appear centered, zoom level 21.
The next thing that's annoying, is that the Mapillary layer is not switched on automatically, so I need to know iD to know where to go to switch it on. That's not entirely intuitive.
Anyway, time to try and create a Mapillary plugin for JOSM.
Then I wanted to upload what I just added. But I couldn't figure out how to add tags to the changeset. In version 2 I managed to add a source, but that ended up on the object. Now this scrawny tree already has 3 versions and none of those changesets have the source information I wanted to add to it.
Verwezenlijkingen mogelijk gemaakt door OSM - Wikidata - Wikipedia - WikivoyagePosted by Polyglot on 29 January 2015 in Dutch (Nederlands)
Gedurende het voorjaar en de zomer van 2014, ontdekte ik een paar interessante plaatsen in Heverleebos en Meerdaalwoud ten zuiden van Leuven. Mijn interesse werd gewekt door een aantal houten standbeelden/sculpturen gemaakt van dode bomen. Ik had deze wel eens eerder opgemerkt, maar had er tot dan nooit veel aandacht aan besteed.
Toen ik er dan uiteindelijk toch eens wat meer over ging opzoeken, ben ik begonnen aan een Artikel over Ad Wouters op Wikipedia. Wist ik veel hoeveel tijd en energie daar zou gaan insteken! Ik was het natuurlijk aan mezelf verplicht om dat te gaan vertalen... En uiteraard had ik ook een kaartje nodig om het te illustreren. Dit heb ik gemaakt met behulp van Maperitive:
Deze kaart is enig in zijn soort. Er worden gegevens van het openbaar vervoer, haltes en routes (lichtblauw en roze) gecombineerd met knooppunten van het wandelknooppuntennetwerk (rood/oranje) en natuurlijk de OSM-data, plus de route die ik wilde beschrijven (blauw). Nog geen 10 jaar geleden was zoiets zelf maken simpelweg ondenkbaar.
En toen ontdekte ik Wikivoyage:
Het loont de moeite om beide taalversies te bekijken. De verschillen onderling zijn groot.
Op de Engelstalige Wikivoyage hebben ze een widget, waarop Openstreetmapdata wordt weergegeven. Het is mogelijk om te schakelen tussen lagen en er transparante lagen overheen te leggen, wat toelaat om de wandel- en fietsknooppuntennetwerken te tonen. Daarenboven is het mogelijk om klikbare POI's in de tekst te vermelden, die dan op de dynamische kaart worden weergegeven.
Bloed, zweet en tranen heeft het gekost om me aan alle regeltjes aan te passen en me in bochten te wringen om eraan te voldoen. 't was nogal een leerervaring, om het zacht uit te drukken. Elk project heeft z'n eigen eigenaardigheden, die natuurlijk totaal verschillend zijn van hoe het er bij OSM aan toe gaat en zelfs van de ene taalversie naar de andere zijn er verschillen.
Uiteindelijk ben ik wel tevreden met het resultaat, al weet ik niet of ik spoedig nog eens aan zo'n projectje zou durven beginnen. Al bij al voel ik me bij OSM toch nog het best in m'n vel.
Achievement made possible by Openstreetmap - Wikidata - Wikipedia - WikivoyagePosted by Polyglot on 29 January 2015 in English (English)
During the spring and summer of 2014, I discovered some interesting places in the forest south of Leuven. My interest was peeked by some wooden statues/carvings made from dead trees. I had seen some of them before, but I hadn't really been paying attention, and they didn't register as a 'collection' until then.
When I did finally investigate further, it lead to the creation of an Article about Ad Wouters on Wikipedia. Of course, I needed to illustrate that with a map, so I created one with Maperitive:
This map is unique in that it combines information about the public transport stops and routes (light blue/pink) and the walking node network (red/orange) and, of course OSM data, together with the route I was describing (blue). Only 10 years ago it would have been impossible to even consider attempting to create such a work.
Subsequently I discovered Wikivoyage:
On Wikivoyage they have a widget, which displays Openstreetmap data. One can switch layers and add overlays, allowing to show the cycle and the walking node network as well, but more importantly one can mention POIs in the text and have them appear on that dynamic map
It took some learning and stumbling. Each of these projects has their own rules and intricacies, which are completely different from OSM, but they are also different among what I consider a family of projects and even from one language version to another. At times they almost drove me mad, but now I'm quite happy with the results. I'm not sure if I'll attempt something similar again any time soon though. Mapping for OSM has its own rewards.
Enabling other mappers to add/update public transport routes in BelgiumPosted by Polyglot on 17 January 2015 in English (English)
Today I put template route relations for itineraries of De Lijn and TEC on Dropbox. Generating them takes 2 hours. And then another 2 hours when I noticed Python hadn't actually compressed them. I'll update them as fresh data from De Lijn and TEC comes in.
I also worked on a script which you can run after opening such a file in OSM.
I put some videos on Youtube to illustrate the process
(no sound was recorded and I still have to add subtitles to them, some day)
The script will download all the stops. They are not included in the files. Once the stops are downloaded the view zooms to their extent.
Then the script will use an Overpass Query to download all route relations with the same ref as identifier. At the moment all over Flanders. I hope I'll find a way to limit it to the bbox you just zoomed to.
For all the nodes on the way, Overpass will download all the nodes which are within 30 meters (and all the ways and relations they belong to).
Now you'll have to run the compare script again. I didn't figure out yet, how to make the script wait until the download completes, so it'll give an error message saying it didn't find the master_routes it was looking for.
When run again, after the download is complete with not objects selected, it'll compare the template routes with the already existing routes. It uses the master_route relations to match them. If the existing routes don't belong to a master_route yet, you'll have to use the template and add the matching existing routes manually. You can leave the template routes, they'll be removed from the master as we progress. Select all the existing and the template routes and close the master route. Now run the compare script again.
You'll end up with a relation which has some funny looking roles. Each letter-number (a0w1i3) combination represents as stop. Now it becomes easier to see which template belongs to which existing route.
Select 2 routes which belong together and press the button to select them in the general window.
Move the window with all the routes out of the way.
Use the other script, which will add ways to the route. At first this script only added the ways adjacent to the stops. At some point I was thinking: why not try to look at the other route relations. Buses tend to all use the same itineraries to get from one stop to the next.
In the mean time the script also copies tags and stops from the template to the existing route relation and it odbl=new. This has the effect that it's shown more prominently with help of MapCSS. Nothing to do with the license. That tag is only used, as it won't 'survive' during upload.
Also the template routes came in tagged with odbl=tttttt. This is what the script uses to identify them as templates.
I'll have to write some posts about how to set up JOSM to enable everybody to use those scripts, the MapCSS and add handy buttons for search and one click presets to the toolbar. One of these days...
Mapping public transport routes (and walking routes)Posted by Polyglot on 15 January 2015 in English (English)
People sometimes ask me: why add all these route relations to Openstreetmap, when De Lijn already has them as shape files?
For one thing, De Lijn cannot share them with us. A good example is the following:
Line sketch on Overpass for De Lijn 91
If you click through to one of the other lines, change the url so it has &style=wuppertal once again at the end. Also keep in mind not each and every line is already mapped, although we're doing quite well in Oost-Vlaanderen.
Another example is a map I rendered where I'm combining the PT network (pink on the background), the walking nodes network (orange) and the route I wanted to talk about:
Only, say 10 years ago, creating such a map would have been an impossible endeavour. It's important for the explanation on this site:
To be able to show where the bus stops are and the walking node numbers are used in the directions, but not exactly used the way they were meant to be used... only to help point people in the right direction, instead of following them from node to node.
Incidentally you'll have to have a look at the Dutch version of the article to see the map used. The English version uses Openstreetmap too, but in a more dynamic way.
MapillaryPosted by Polyglot on 14 January 2015 in English (English)
I attended a meeting of the Peruvian community on Saturday. Somebody showed us the capabilities of Mapillary. Of course, I'm hooked already.
Soon the parts of the city and surroudings I frequently visit will be visible on Mapillary.
I've been waiting for a long time for a way to link back to pictures I took during my surveys. Wikimedia Commons is no good for this, all the worthwhile pictures I uploaded there got nominated for deletion. So I gave up on them.
Mapillary looks promising. If it were up to me they'd get a dedicated tag all for themselves:
But I also gave up on the voting process on the wiki. Even if a vote's result are positive, that doesn't mean or guarantee that that scheme will be rendered by the powers that be (yes, I'm talking about the 'new' public transport scheme).
So I'll probably simply start using that tag and be done with it.
Mapping public transport in BelgiumPosted by Polyglot on 10 January 2015 in English (English)
This article is inspired by http://blog.openstreetmap.de/blog/2014/12/wochenaufgabe-kw-5152-oepnvfahrplanwechsel/ but adapted to how public transport is mapped in Belgium at the moment.
I also recorded an editing session in JOSM:
Add bus route in Antwerp Belgium
Apparently public transport companies do all the major changes to their time tables towards year's end. At least this seems the case for both Germany and Belgium. So we have some changes to process in Belgium as well.
In Germany they have weekly assignments. I guess that, over here, cleaning up the mapping of public transport, will become a task, that takes somewhat longer than a week to accomplish.
We also still have quite a large amount of lines that are mapped in the now deprecated way, using just one route in a futile attempt to describe all its variations. If all you wanted to do, is render on a map where the buses pass, this may be sufficient, but in case you want to describe actual itineraries, that is severely lacking. Those older routes take the longest to convert, but at least there is an approximate indication of the itinerary when they are present.
We have, however, many routes which are already on 'version 2'. The problem with those is that they are prone to change to the timetables/itineraries and they get broken by edits with inferior editors, which don't process relations properly.
This got me thinking about a way to:
keep them up-to-date in a practical way?
I've been working on scripts to automate the boring parts of this arduous task. The source code can be found here:
and here:
Incidentally those scripts also help when creating routes for bus and tram lines which aren't in OSM yet.
They depend heavily on the availability of PT data from De Lijn and TEC though. So their performance is optimal when such data is available, which isn't the case for the Brussels' operator MIVB/STIB, unfortunately. Those can be added in more traditional ways, but instead of starting from the stops to add an itinerary afterwards, it may make more sense to work the other way around.
On to the translation/adaptation of the German week assignment
Mapping public transport in OSM is a subject which is often poorly understood. The consequence is a multitude broken route relations, which don't get updated. For users of the data this is rather worthless. At the time of writing, it seems like 3, and possibly a few other, mapping schemes are in use (I found out recently that we deviate from what the wiki proscribes in Belgium as well, this article was started to describe at which points in detail).
Before starting to edit, some research might be needed. Does the route_master relation still describe an existing bus/tram line? Do the route relations still describe actual variations accurately?
Sometimes lines get new identifiers (line numbers). This occurred in Beringen recently:
Beringen krijgt nieuw busnet vanaf 14 juli
I worked on updating those over the past week (Jan 2015). The changes happened in July 2014 though, I'm working on a way to detect such changes in a more timely way and to present to the community at large through a web interface.
To map public transport, you'll need an editor which can work correctly with relations, iD is not up to that task, as it's not possible to influence the order of the members with iD. And the order of relation members is crucially important in public transport route relations. (It is important in our cycle/walking node relations as well, if you want to do automatic validation on them, but that's another story).
JOSM is the only suitable editor to accomplish this task and not only because of the relation editor, but also because it's the only editor which supports the MapCSS to properly visualise the data and a scripting environment to use the scripts I created to help with the task.
New routes and all the ones we bring up-to-date, should be mapped according to the 'new' Scheme. For Belgium it's described here:
http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Bus_and_tram_lines Stops/Stations
In the new scheme a separation is made between where the passengers wait and where the (front of the) bus/tram/train halts on the way. The latter is mapped as a node which is part of the way. Although all stops of De Lijn and TEC are now in OSM, these stop_positions were not always added. Please add them if you are already editing/splitting the way for other purposes.
for bus stops add bus=yes
for tram stops add tram=yes
for train add train=yes
These nodes don't get extra information like name, ref, route_ref or zone. (at least in Belgium they don't)
When this serves as a terminal/initial stop for some of the served line variations, split the way at this point.
In case a platform is present, this can be entered as a way or an area.
To get them rendered add:
highway=platform for bus stops
railway=platform for tram stops
In case of a closed way for an area add
At the moment I haven't found a reason to use multipolygon relations for these.
In Belgium, these platforms don't get any extra tags, except for tactile_paving=yes/no if a way was used to map it and those foot massagers are present.
In case of an area was used for mapping the platform, it's probably better to add a highway=footway with tactile_paving=yes. The imagery of AGIV is good enough to determine where their extremities are. They look like white T's
Platform nodes
To keep things simple and manageable all bus and tram stops in Belgium are mapped on nodes. I never considered moving the details like name, ref, route_ref and zone to platform ways, as that would result in them not being shown anymore by the MapCSS style I created for that purpose.
These nodes can designate the position of the pole, a corner on the shelter where the 'flag' is mounted, or if this is unknown, the position of the B of the word B U S, if visible on the aerial imagery.
In Belgium all bus and tram stops of De Lijn and TEC are now mapped, most of them by yours truly. (Click on the links if you want to download files converted to OSM format for verification). In case the position could not be determined from the aerial imagery these positions are approximate until somebody surveys and moves them.
TEC also provides shapefiles, which I converted to GPX. This is mostly interesting to know which streets the buses are likely to follow and to exclude the streets where they most certainly don't go.
In Brussels we can't seem to get permission to access to the data of MIVB/STIB, but the exact positions of the poles are in the dataset of UrbIS, which we are allowed to use. So we should be able to map the PT network in Brussels the (mostly) traditional way. UrbIS contains the tram rails as well. It's quite an undertaking to integrate them in OSM, but once they're in, it becomes trivial to add the tram lines. If you provide me with GPX files of your bus rides on lines in Brussels, I might even add/update them for you.
Some stops of De Lijn and TEC extend into the Brussels Region, The Netherlands, Germany, Luxembourg and France. All these were added to OSM as well. In fact, I did those first, to find out which was the best way to do so. At first I used dedicated nodes per operator, but that's not the proper way, after all (I was never entirely happy with doing it that way, but it had a few advantages as well in case some fields didn't happen to agree). Now each operator got their own 'namespace' and those nodes should all be merged by now.,
for bus stops add bus=yes
for tram stops add tram=yes
for train add train=yes
For backward compatibility and to get them rendered:
add highway=bus_stop or railway=tram_stop
All bus/tram stop nodes have a unique ref to identify them. To make it possible to use a single node for multiple operators, these are mapped as:
ref:De_Lijn ref:TECB ref:TECC ref:TECH ref:TECN ref:TECL ref:TECX
Indeed, each entity of TEC assigned their own identifiers and for buses which wander into another provinces the stops have more than one.
For Veolia, Connexxion, MIVB/STIB, etc we can safely use:
But mostly we don't have identifiers for these.
Sometimes it's necessary to use separate namespaces for name as well:
When 2 entities of TEC don't happen to agree on the name to use, I just picked 1, mostly arbitrarily.
At some point we decided to include the name of the municipality as part of the name:
Blanden Kerk
Haasrode Kerk
Making an exception for the larger cities like Antwerp, Brussels and Ghent. In retrospect I would prefer to start prepending Gent as well. For Charleroi and Liège, I simply included them as part of the name. For stops outside of Belgium this is not customary. For bilingual areas, I also dropped the village/city names, as they become rather long otherwise.
The same applies to route_ref. This tag includes all the lines which serve this bus stop.
For QC purposes one could also include not_served_by for those stops skipped by express buses, or when it's not possible to serve them as the bus makes a left turn across 2 lanes soon after where the halt is located.
It's possible to include
* shelter=yes/no
* covered=yes/no
* bench=yes/no
* bin=yes/no
Or it's possible to map these as separate elements:
* amenity=shelter
* shelter_type=public_transport
* amenity=bench
* amenity=waste_basket
* building=roof
for bus stations you can add a node or an area tagged as
* amenity=bus_station
stop_area relations
All of the above can be collected in a stop_area relation. One stop_area relation for each highway=platform node. So in simple cases one for each side of the road.
stop_area_group Relations
All stop_area relations can be collected in stop_area_group relations. JOSM will complain about these. Let it. The validator may catch up some day, or not. They were in the initial 'new' PT scheme, and then they were dropped for some inexplicable reason.
Once the stops are mapped according to 'PTv2' - we can start adding route relations for all the variations. The good news is that in Belgium almost all stops have been added by now. The exception are those stops in Brussels which don't get served by De Lijn or TEC. Add OSM notes to the map with all their details and send me a link to the note for those, if you don't feel comfortable adding them directly.
Route Relations
In PTv2 there is one route relation per variant. So the simplest lines will have 2 variants, one for each direction (The exceptions confirming the rule are the Ringbus 600 and 601 in Leuven and some school buses like 586). The good news is that we can compile route relations for each of these variants automatically for lines run by De Lijn and TEC.
To keep the number of variants (and the work to keep them up-to-date) limited we only have a variant for the longest sequence of stops for telescopic routes. I believe it makes sense to save contributors' precious time and to limit the number of route relations, ways need to be members of. For rendering there is no difference (except that it means less processing) and for routing, it's relatively easy to cut out the ways sequence which is needed for a shorter sequence of stops. (I know it can be done, as I've scripted exactly that to assist contributors when creating new route relations)
Each route relation has all the stops at the end. These are the platform NODES mentioned higher up. These are the only nodes the conversion scripts know about, so these are the nodes which can be added automatically to the template routes it creates. Their order matters, of course. At some point I made the arbitrary decision to have the ways first, followed by the stops, as that's the way JOSM would sort them (if you were foolish enough to let it do that on all the members of the relation at once. JOSM can sort the ways fine, but it's smarter to give it a subset of just ways. It doesn't cope very well if ways are used more than once (loops, spoons)).
Apparently the wiki contradicts this and proscribes stops first, then ways. Ultimately I don't think it matters much, unless it would cause 'edit wars'. I prefer to have the ways first, as that is what contributors work on. The stops are added by a script, at least in our case.
If the bus uses a way more than once, it will be in the route more than once. The same goes for the stops, which get served more than once by the same variant. This is less common than ways being used more than once.
Master_route Relations
All variant routes belonging to the same line are collected in a master route relation.
Challenge: keep it all up-to-date
I will come up with a script which can make an overview of which routes are in need of attention. Hopefully I can get an account on a dev server to do so.
JOSM is driving me crazyPosted by Polyglot on 24 September 2010 in English (English)
I found a nice little feature in JOSM: q makes rectangles with 90 degree angles. They look perfect while still in JOSM. Then it gets rendered and I end up with parallellograms. What's up with that? (and more importantly: what can I do to prevent it?)
Cusco PeruPosted by Polyglot on 13 July 2009 in English (English)
I'll be mapping in and around Cusco for the next 5 weeks.