FoonSearch 2004 (php versie)

alkema_jm · 22 oktober 2004 om 16:30

Hoi Xim (, RGJ)

Ik zoek op telefoonummer 0742455490

Blijkbaar wordt er de volgende SQL query gemaakt.

select white_subscriber.*, (housenumber+0.00) as housenr, count(white_info.id) as cnt from white_subscriber ,white_phonenumbers left join white_info on white_info.id = white_subscriber.id where white_phonenumbers.phonenumber=‘0742455490’ and white_phonenumbers.id = white_subscriber.id group by white_subscriber.id, white_info.id order by postalcode,housenr limit 1004 vermeldingen gevonden (0.069 seconden);

Ik zie drie resultaat records. Eigen zou je graag willen dat de record met “Piano- Orgel- en Muziekhandel Schumer” samengevoegd wordt tot 1 record. Hoe kan dat het gemakkelijkst in SQL?

Als je naar 0356030028 kijkt zou deze ook samengevoegd kunnen worden, echter beide entries bevatten een info record. RGJ, de ene heeft bij jou nog een rare “PV veld”.

De vriendelijke groet Jan Marco

rgj · 22 oktober 2004 om 17:02

De drie resultaat records zijn verschillend, namelijk:

Piano- Orgel- en Muziekhandel Schumer met info record
Piano- Orgel- en Muziekhandel Schumer zonder info record
Schumer Piano- Orgel- en Muziekhandel

Je kan ze dus niet samenvoegen.

De entries voor 0356030028 kan je ook niet samenvoegen. De info records zijn namelijk verschillend. Het zijn dus verschillende entries, want aan een info record kunnen weer verschillende telefoonnummers hangen.

Voor zover ik weet staat dat PV veld in de gids en dus dump ik het met Foondump en toon ik het met foonsearch. Ik zie niet in waarom ik code moet bouwen die dat eruit haalt.

Wat bedoel je met ‘bij mij’ een raar PV veld ? Dat het in jouw dump niet voorkomt?

alkema_jm · 23 oktober 2004 om 06:29

Hoi RGJ,

Erg mooi gemaakt die foonsearch php versie --)

Best leuk te zien hoe je van white naar pink en visa versa kan overgaan.

Wat bedoel je met ‘bij mij’ een raar PV veld ? Dat het in jouw dump niet voorkomt?

Ik heb geen php draaien op Windows, dus zit bij jou te testen.

De drie resultaat records zijn verschillend, namelijk:

Piano- Orgel- en Muziekhandel Schumer met info record

Piano- Orgel- en Muziekhandel Schumer zonder info record

Schumer Piano- Orgel- en Muziekhandel

Je kan ze dus niet samenvoegen.

Even in wiskunde uitgelegd.

Laat A de verzameling van “Piano- Orgel- en Muziekhandel Schumer” zijn.

Laat B de verzameling van de info records zijn behorende bij de “Piano- Orgel- en Muziekhandel Schumer” entry.

Jij laat het volgende tonen: A OF (A OF B)

M.i. kan je dit reduceren tot A OF (A OF B) = A OF B

De entries voor 0356030028 kan je ook niet samenvoegen. De info records zijn namelijk verschillend. Het zijn dus verschillende entries, want aan een info record kunnen weer verschillende telefoonnummers hangen.

Ik betwijfel over er wel twee records zijn. In de ene inforecord staat “Sinds 1982 de grootste van Nederland”. De tekst kan ik niet in de cdfoon ZM4 terugvinden. Net of deze tekst bij een andere entry hoort.

Ik heb wel even gekeken het is wel een white info record. Ik weet dat er iets met de pink info records aan de hand was. N.B. Pink info kan bij jou nog niet goed gedumpt zijn.

Voor zover ik weet staat dat PV veld in de gids en dus dump ik het met Foondump en toon ik het met foonsearch. Ik zie niet in waarom ik code moet bouwen die dat eruit haalt.

Kijk even in de cdfoon ZM4 bij plaatsnaam Soest en naam Wiegers.

Ik zie maar 1 inforecord met alleen “www.luchtballonvaart.com en Wiegers Ballonvaart BV Rob” toegevoegd:

Wiegers Ballonvaart BV Rob
Peter van den Breemerweg 9
3768 MP Soest
(035) 603 00 28

Mogelijk is PV = “Wiegers Ballonvaart BV Rob”

Maar “Wiegers Ballonvaart BV Rob” kan best de fullname zijn.

Het zou best kunnen zijn dat er iets fout in zit.

De vriendelijke groet Jan Marco

rgj · 23 oktober 2004 om 09:12

[quote=“alkema_jm”]Even in wiskunde uitgelegd.

Laat A de verzameling van “Piano- Orgel- en Muziekhandel Schumer” zijn.

Laat B de verzameling van de info records zijn behorende bij de “Piano- Orgel- en Muziekhandel Schumer” entry.

Jij laat het volgende tonen: A OF (A OF B)

M.i. kan je dit reduceren tot A OF (A OF B) = A OF B[/quote]

Ik begrijp niet hoe B gedefineerd is. Een info record hoort niet bij ‘de’ Pianohandel Schumer entry, maar bij ‘een’ entry voor Pianohandel Schumer.

Daarnaast impliceert A OF (A OF B) dat de verzamelingen A en B op dezelfde wijze getoond worden.

Nieuwe poging.

R is de verzameling van alle resultaten op een zoekopdracht.
Dus R = {r1, r2, … }

I is de verzameling info records bij een resultaat. Dus Ir1 = {i1r1, i2r1…} en Ir2 = {i1r2, i2r2…}

Jij zegt: Indien rx = ry toon dan rx (Irx V Iry). Waarbij geldt dat rx=ry, indien (slechts) het toonbare deel van de informatie in rx en ry identiek is.

Ik zeg: Dat is lastig om in SQL op te lossen, met name omdat rx en ry een niet-toonbaar deel hebben (een id en een pointer naar de info records) die niet gelijk zijn, terwijl een mens toch vindt rx=ry.

[quote]>De entries voor 0356030028 kan je ook niet samenvoegen. De info records zijn namelijk verschillend. Het zijn dus verschillende entries, want aan een info record kunnen weer verschillende telefoonnummers hangen.

Ik betwijfel over er wel twee records zijn. In de ene inforecord staat “Sinds 1982 de grootste van Nederland”. De tekst kan ik niet in de cdfoon ZM4 terugvinden. Net of deze tekst bij een andere entry hoort.
[/quote]
Hmm, als ik naar www.luchtballonvaart.com ga dan zie ik daar staan:
Welkom bij Rob Wiegers Ballonvaart BV, de grootste en goedkoopste in ballonvaarten, sinds 1982.
Het lijkt me dus plausibel dat er onder een ander trefwoord nog een vermelding is die je nog niet hebt gevonden.

alkema_jm · 23 oktober 2004 om 09:31

Hoi RGJ,

Erg bedankt voor jouw terugkoppeling --)

Ik zeg: Dat is lastig om in SQL op te lossen,

Zal volgende week even aan database specialisten vragen of dit puzzeltje op te lossen is.

Het lijkt me dus plausibel dat er onder een ander trefwoord nog een vermelding is die je nog niet hebt gevonden.

Je heb gelijk --)

Wel mooi die koppeling tussen informatie.

Bij “mijn” kledingwinkel (telefoonnummer = 0596-612081 ) kan ik direct zien wie de eigenaar is.

De vriendelijk groet Jan Marco

Weerman · 23 oktober 2004 om 14:08

Zo?

Eerst van ‘Info’-regels kolommen maken (“Info_Crosstab”, Access Jet-SQL):

TRANSFORM First(infovalue) AS FirstOfinfovalue SELECT fullname, streetname, housenumber, housenumberextension, postalcode, townname, areacode, subscribernumber, lineno FROM (white_phonenumbers LEFT JOIN white_subscriber ON white_phonenumbers.id=white_subscriber.id) LEFT JOIN white_info ON white_phonenumbers.id=white_info.id WHERE phonenumber="0742455490" GROUP BY fullname, streetname, housenumber, housenumberextension, postalcode, townname, areacode, subscribernumber, lineno PIVOT recno;

Met een ‘UNION’ ontdubbelen:

SELECT -4 AS lineno, fullname AS info FROM Info_Crosstab UNION SELECT -3 AS lineno, [streetname] & " " & [housenumber] & " " & [housenumberextension] FROM Info_Crosstab UNION SELECT -2 AS lineno, [postalcode] & " " & townname FROM Info_Crosstab UNION SELECT -1 AS lineno, [areacode] & "-" & [subscribernumber] FROM Info_Crosstab UNION SELECT lineno, Trim$([0] & " " & [1] & " " & [2] & " " & [3] & " " & [4] & " " & [5]) FROM Info_Crosstab WHERE [0]<>"" ORDER BY lineno;

Resultaat:

lineo info -4 Piano- Orgel- en Muziekhandel Schumer -4 Schumer Piano- Orgel- en Muziekhandel -3 Pasmaatweg 50 -2 7556 PH Hengelo ov -1 074-2455490 0 K4RR 2 tevens verhuur-reparatie-stemmen 3 vertegenwoordiger van alle bekende merken 4 074 2455490 Pasmaatweg 50 7556PH Hengelo ov

alkema_jm · 23 oktober 2004 om 17:55

Hoi Weerman,

Erg bedankt voor jouw terugkoppeling —)

Als je naar 073-5999999 kijkt heb je drie records voor het zelfde bedrijf.

Mogelijk 1 tonen en daarna op full name kunnen klikken en in het scherm wat dan komt de alternatieve namen tonen. Mogelijk record kiezen die meeste voorkomt in hoofdentry.

Als je naar 053-4885995 kijkt dan houd je 2 records(/regels) over als je jouw code en mijn bovenstaand voorstel implementeert van de huidige 5 regels.

De vriendelijke groet Jan Marco

alkema_jm · 29 oktober 2004 om 06:53

Hoi RGJ,

Als ik naar 0546-589300 kijk:

Telefoon Naam Adres Postcode Plaats
0546-589300 Twente Vandaag
0546-589300 Twente Vandaag
0546-589300 Twente Vandaag
0546-589300 Twente Vandaag
0546-589300 Twente Vandaag Bedrijvenpark Twente 165 N 7602 KE Almelo

Dan zou m.i. alleen 1 hoofd record getoond hoeven te worden:

Telefoon Naam Adres Postcode Plaats
0546-589300 Twente Vandaag Bedrijvenpark Twente 165 N 7602 KE Almelo

Met “OF” verzameling van alle info records:

PVR
Postbus 21 7670AA Vriezenveen
Fax 0546-570119
Advertentie afdeling 0546-589320
www.twentevandaag.nl

Mogelijk zal je het “inforecordtotaal” van bovenstaande nummer moeten sorteren/laten zien op het scherm in een bepaalde structuur.

De vriendelijke groet Jan Marco

XiM · 29 oktober 2004 om 15:39

Eerst even een waarschuwing vooraf, ik heb nog geen dump van een recente cdfoongids en mijn dump is ook gemaakt met een oude foondump. Dus mijn voorbeelden kunnen eventueel afwijken van wat iemand anders vindt met een vergelijkbare query.

Ik denk dat de vraag van alkema_jm de verkeerde vraag is. Je zou niet moeten vragen “hoe moet ik mijn dubbele resultaten samenvoegen”, maar “hoe kom ik aan dubbele resultaten waar ik er maar een enkele verwacht” en dan pas “wat doe ik daar aan”. Eerst maar het eerste gedeelte van de vraag, “hoe kom ik aan meerdere resultaat records”. Als we kijken naar telfoonnummer 0742455490 en even alle kolommen die alle records gelijk hebben weglaten krijgen we het volgende lijstje:

phn_id phn_phonenumber phn_type sub_id sub_lastname 1866120 0742455490 0 1866120 Piano- Orgel- en Muziekhandel Schumer 2780153 0742455490 0 2780153 Piano- Orgel- en Muziekhandel Schumer 2780153 0742455490 9 2780153 Piano- Orgel- en Muziekhandel Schumer 2783304 0742455490 0 2783304 Schumer Piano- Orgel- en Muziekhandel

De kolommen beginnend met phn_ komen uit de phonenumbers tabel en beginnend met sub_ uit de subscriber tabel. Hier is te zien dat het probleem uit 2 onderdelen bestaat. Ten eerste onstaat er een dubbel resultaat als gevolg van 2 verwijzingen vanuit de phonenumbers tabel (1x type 0 en 1x type 9) naar hetzelfde record (zelfde sub_id) in de subscriber tabel. Dit probleem levert dus in de resultaten twee keer hetzelfde subscriber record op. Dit kan je oplossen door je query aan te passen. Afhankelijk van welke informatie je wil kan het met een simpel DISTINCT of heb je iets uitgebreiders nodig zoals een subquery. Maar het is netjes op te lossen.
Ten tweede wordt er vanuit de phonenumbers tabel naar 3 verschillende subscriber records verwezen (IDs 1866120,2780153,2783304). Ik denk dat het een verkeerd idee is om dit samen te gaan voegen. Het zijn aparte records en zouden dan ook apart uit de DB moeten komen. Het is ook technisch niet mogelijk zonder bepaalde informatie weg te gooien. Neem bijvoorbeeld IDs 1866120 en 2780153. Alle kolommen in subcriber behalve seq en id van die records komen overeen. Je zou dus seq en id niet in je SELECT op kunnen nemen en vervolgens met DISTINCT er 1 resultaat record van kunnen maken. Maar dan heb je wel de ID informatie weg gegooid die je bijvoorbeeld nodig hebt om later de informatie uit de info tabel te halen nodig hebt. Als je het toch persé wil samenvoegen lijkt me dat iets om buiten de DB om te doen, dus in je applicatie.

Wat me wel interessant lijkt is te kijken naar hoe deze ogenschijnlijk dubbele records onstaan. Is het een bug in foondump, is het een probleem inherent aan de manier waarop foondump de data verkrijgt, of staat het ook exact zo in de database van de cdfoongids of nog iets anders? Dat kan waarschijnlijk aangeven of er überhaupt een oplossing bestaat, want onder de huidige omstandigheden is het m.i. niet moglijk om het automatisch op te lossen. Er is gewoon handwerk nodig om records samen te kunnen voegen en zelfs dan weet ik niet zeker of er geen probleem gevallen over blijven. En met 6 miljoen records is handwerk alleen een theoretische oplossing. Althans vantevoren, want at runtime gebruiken we natuurlijk al de handwerk oplossing, je kan namelijk meestal in 1 oogopslag zien welke records dubbel zijn :).
Ik heb dan ook persoonlijk niet zo’n probleem met de huidige situatie van dubbele resultaten, maar het is inderdaad niet 100% ideaal.

Weerman · 30 oktober 2004 om 12:24

Denk dat ze de data voor het boek-op-papier en de nieuwere media - dus cd en internet - niet goed uit elkaar kunnen houden. In het boek wil men graag gesorteerd onder Schumer en bij Pianos gevonden worden, dus daar hebben ze iets slims voor verzonnen: meer dan één vermelding. Deze hobbel valt weg als je electronisch zoekt maar het is tot op heden kennelijk niet gelukt om dat in de database-opzet te verwerken:

U heeft gezocht naar [b]Schumer[/b] in [b]Nederland[/b] Resultaat [b]1 - 18[/b] van [b]18[/b] vermeldingen.Achtien keer hetzelfde telefoonnummer via telefoongids.nl. Zal wel een vermelding in iedere regio zijn en daartussen zit drie keer een "Schumer BV"-vermelding uit het Roze katern die we nog niet hebben laten zien.

Zoveel vermeldingen en evengoed kan je Schumer nog steeds niet faxen.

Daarvoor moet je naar de Goudengids. Voor faxnummers kan je beter terecht bij de Goudengids ondanks dat ze afgeknepen worden door de KPN die alleen maar verplicht het telefoonnummer uit de hoofdvermelding afstaat en geen extra vermeldingen. Omdat ze zelf werven bij bedrijven heeft de Goudengids een groter faxnummerbestand, dwz. van bij de KPN uitgegeven telefoonnummers waarvan bij de Goudengids bekend is dat de abonnnee het voor faxen bestemd heeft.

Maar ook de Goudengids heeft ‘merge’-problemen. Op hun CDrom is te zien dat er een massieve operatie gaande is om de eigen rubrieken en de faxnummers te gaan vermelden naast de vernieuwde straatnaam-schrijfwijze van de gegevens in de “witte” telefoongids die ze van de concurrent gekregen hebben. Bij Schumer is dat nog niet gedaan, geen vermelding van rubriek of faxnummer voor hen in de Nationale telefoongids en wel in de Goudengids maar de lijn is toch dat de faxnummervermeldingen in het Goudengids helemaal opdrogen, faxnummers staan nu allemaal in het Nationale gids-gedeelte. Volgende week komt versie 8 uit, kijken hoe dat verder uitpakt.

rgj · 30 oktober 2004 om 17:40

Het zit net iets anders. Het is deels het dump-proces en deels de opbouw van de gids.

Ze doen het als volgt:

een vermelding kan in meerdere plaatsen voorkomen.
een vermelding in een plaats kan onder meerdere trefwoorden voorkomen
wordt gekozen door de abonnee
wordt automatisch gedaan door alle losse woorden van de naam te splitsen en veel voorkomende tussenvoegsels e.d. eruit te filteren. Dat kan goed uit de hand lopen, bijvoorbeeld de entry “Hankamp Gert Jan en Thije Linda Ten” komt dus onder 6 trefwoorden voor (alleen en sneuvelt in het filter).

De enige manier van dumpen is door plaatsen af te lopen, vervolgens de trefwoorden en dan de vermeldingen.

Stel dat Gert Jan en Linda besloten hebben dat ze zowel in Aalsmeer als in Lutjebroek vermeld willen worden, komt het dump proces dit stel dus in 2 plaatsen x 6 trefwoorden = 12 keer tegen.

Binnen een plaats filtert Foondump de dubbele vermeldingen er weer uit door alleen entries die beginnen met hetzelfde woord als het trefwoord, in acht te nemen. In dit voorbeeld wordt de vermelding dus alleen gedumpt bij het trefwoord ‘Hankamp’.
NB. dit werkt niet perfect. Een vermelding van broer en zus zoals ‘Jansen Jan en Jansen Mariska’ wordt twee keer gedumpt door Foondump. Omdat een slimmer algoritme het dumpen ernstig zou vertragen heb ik besloten hiermee te leven.

Bij het ontdubbelen van vermeldingen in verschillende plaatsen zou Foondump bij elke vermelding de hele database moeten doorzoeken. Helaas lukt het niet de primary key van de CDFoongids zelf uit de database te krijgen.

Blijft over dat de Pianohandel volgens mij gewoon 2 x het formuliertje van Telemedia heeft ingevuld.

Weerman · 30 oktober 2004 om 20:26

Ben nog niet overtuigd. Buiten de CD en het dumpen daarvan om zie je het ook gebeuren:
Telefoongids.nl-wit komt voor Pianos in Hengelo met een “Piano- Orgel- en Muziekhandel Schumer”-vermelding en een omgedraaide “Schumer Piano- Orgel- en Muziekhandel”-vermelding. Maar niet verder uitgesplitst naar vermeldingen die beginnen met Orgel- of met Muziekhandel.

Wat ik al dacht, er is een regio-effect: verruim ik naar “Hengelo en omstreken” dan komt er een derde Schumer-vermelding bij, die voor de regio. Bij elkaar precies de drie waar Jan Marco zich aan ergerde.

Pianos in Amsterdam geeft op de tweede plaats? Schumer Piano- enz. te Hengelo. Toch een heel eind met een piano. Daarom krijg je zoveel identieke resultaten als je het webzoekscherm op heel Nederland instelt. Een van de drukst bezochte websites van Nederland en dan zoiets tonen.

Zeker, je kan wel zoeken op permutaties zoals Orgel of Muziekhandel maar je krijgt dan toch de twee eerder genoemde vermeldingen terug.

Daarom denk ik dat ze zulke papieren “zoekingangen” op Naam en Rubriek (Schumer en Pianos) “hardgebakken” invoeren. Er lijkt niet voldoende ‘decompositie’ aangebracht in het systeem om de verschillende uitgaven fatsoenlijk te bedienen en dus duiken Rubriek, Naam en Regio steeds in combinatie op ongeacht het medium, eventueel zelfs achttien keer. Er bestaan trouwens stukken die voor zoveel pianos geschreven zijn weet ik toevallig.

alkema_jm · 31 oktober 2004 om 06:17

Hoi Weerman, Xim, RGJ,

Erg bedankt voor jullie terugkoppelingen —)

Je kan de database opschonen om eenduidige output te krijgen. Of je gaat de output bij representatie eenduidig maken. Het probleem met het eerste voorstel is dat je geen directe grip op de informatiedatabase hebt.

Omdat je meer dan 1 informatie bron hebt (white, pink, goudengids, postcodepro, etc) zal je m.i. altijd op het eind iets moeten doen.

Bedrijven (pink):

Telefoon Naam Adres Postcode Plaats

026-3831518 FunPrice Computers Looierstraat 11 6811 AT Arnhem

055-5790746 FunPrice Computers Hoofdstraat 153 7311 AV Apeldoorn

053-4346473 FunPrice Computers Korte Hengelosestraat 14 7511 JB Enschede

050-3113938 FunPrice Computers Oude Ebbingestraat 39 9712 HB Groningen

Telefoongids (white):

Telefoon Naam Adres Postcode Plaats

026-3831518 FunPrice Computers Looierstraat 11 6811 AT Arnhem

055-5790746 FunPrice Computers Hoofdstraat 153 7311 AV Apeldoorn

053-4346473 FunPrice Computers Korte Hengelosestraat 14 7511 JB Enschede

050-3113938 FunPrice Computers Oude Ebbingestraat 39 9712 HB Groningen

Persoonlijk zou ik bij het zoeken in allebei gaan zoeken “Bedrijven (pink)” en “Telefoongids (white)”. Het resultaat gaan mergen. Als je het laat zien mogelijk wel achtergrond kleur verschil aanbrengen om te laten zien in welk gedeelte de info van de cdfoon komt.

Het probleem met het eerste voorstel is dat je geen directe grip op de informatiedatabase hebt.

Met de online variant kan je straks als eind gebruiker de info van foondump aanpassen.

Bijvoorbeeld: Ik zie in een folder dat er een huisartsenpost in Oldenzaal komt vanaf 1 november 2004 met nummer 0541-536769. Deze kan ik straks gewoon intoetsen en daarna nemen de peer servers deze info direct over.

Zoveel vermeldingen en evengoed kan je Schumer nog steeds niet faxen. Daarvoor moet je naar de Goudengids. Voor faxnummers kan je beter terecht bij de Goudengids ondanks dat ze afgeknepen worden door de KPN die alleen maar verplicht het telefoonnummer uit de hoofdvermelding afstaat en geen extra vermeldingen.

Weerman, Straks gewoon de faxnummers er in proberen in te voegen en daarna kan je deze nieuwe info laten synchroniseren met je buurservers —)

N.B. Het fax gebruik loopt terug, daarentegen zal het aankoppelen van www. Adres aan entry wel een belangrijk doel worden. Mensen zullen m.i. straks meer gaan zoeken in een telefoonboek om de site/email bedrijf/persoon te gaan opzoeken.

De vriendelijke groet Jan Marco

Weerman · 7 november 2004 om 17:27

Hoi Jan Marco, paar dingen. Eerste punt, op het oude forum stonden cijfers van eind 2002 over het gebruik van de verschillende gidsen:

[code]Bron %

witte pagina’s van de telefoongids 38
telefoongids van KPN op Internet 28
de CD Foon gids (CD-Rom) 11[/code]
Mogelijke conclusie: bezoekers van dit forum kijken er een beetje anders naar omdat zij zich meer dan gebruikelijk richten op de Cd-romgids. In werkelijkheid wordt er vaker naar het papieren telefoonboek gegrepen en dat zal dan wel van invloed zijn als ze beslissingen moeten nemen over het anders inrichten van de telefoonnummerdatabase. Misschien hebben ze daarom niet zo’n haast met een verbeterde CD.

In dat opzicht loop jij je tijd vooruit, jij ziet louter elektronische opslag en de mogelijkheden daarvan.

Tweede punt betreft jouw lijstje telefoonnumers voor Funprice Computers, ook aan jouw opsomming is te zien dat er iets aan de hand is met die tweede, identieke vermelding.

Zoals ik al eerder schreef, dat lijkt iets te maken te hebben met ruimer zoeken in de regio maar in het geval van Pianoverkoper Schumer zou je nog aan iets anders kunnen denken, die betaalt namelijk voor zgn. “Digitale Advertenties” en krijgt daarvoor doorklik-links, zowel op internet als in het roze gedeelte van de CD-foongids. Men komt dan uit bij pagina’s als deze: http://da.detelefoongids.nl/13703917

Funprice Computers betaalt daar niet voor maar ook zij worden toch vaker vermeld dan je zou verwachten.

Dubbele vermeldingen toch vanwege regio’s? In de zoekpagina van Telefoongids.nl kan je ook “Uitgebreid zoeken” o.a. met selecties op provincie of regio. “Uitgebreid zoeken in provincie Gelderland” naar Funprice brengt je in Apeldoorn en Arnhem, provincie Groningen geeft de stad Groningen, zoeken in Overijssel Apeldoorn en Enschede en via de provincie Utrecht kom je weer uit in Arnhem.

Zucht…

Zoeken in een regio dan. Daarvoor kan je een
http://www.telefoongids.nl/popup_map_who.html][u]kaartje[/u
openen en zien welke regio’s er bijvoorbeeld in Gelderland passen. Nieuwe zoekopdrachten voor Funprice in die verschillende regio’s: voor Regio 30, 33 en 34 sturen ze je naar Funprice in Apeldoorn, voor Regio 36, 37 en 38 kan je beter naar Arnhem gaan.

Ok, nu de CD. In het zoekprogramma op de CD-foongids kan je niet op regio selecteren. Zou je als alternatief de optie “Postcodegebied” kunnen gebruiken? Ja, met zoeken in Arnhem krijg je Funprice maar 1 keer terug en opeens 2 keer via de vier cijfers van hun postcode.

Dus het CD-foon-zoekprogramma ziet op een of andere manier kans om onderscheid te maken tussen een enkele vermelding voor Funprice Computers in de plaats Arnhem en een tweede, identieke, vermelding voor het postcodegebied 6811.

Mijn vraag zou zijn: op basis van wat voor informatie kan de CD-foongids dat doen en kan Foondump daar dan niet ook op ziften?

alkema_jm · 12 november 2004 om 15:58

Hoi Weerman,

Mogelijke conclusie: bezoekers van dit forum kijken er een beetje anders naar omdat zij zich meer dan gebruikelijk richten op de Cd-romgids. In werkelijkheid wordt er vaker naar het papieren telefoonboek gegrepen en dat zal dan wel van invloed zijn als ze beslissingen moeten nemen over het anders inrichten van de telefoonnummerdatabase. Misschien hebben ze daarom niet zo’n haast met een verbeterde CD.

Misschien hebben ze daarom niet zo’n haast met een verbeterde CD.

Ik denk dat de “cdfoon achtige bedrijven” vaak niet zo veel met strategie en nieuwe visie bezig zijn. Ik geloof dat de aandeelhouders/eigenaren vaak investeringsmaatschappijen zijn en die willen het alleen maar gaan uitmelken.

In dat opzicht loop jij je tijd vooruit, jij ziet louter elektronische opslag en de mogelijkheden daarvan.

In mijn visie moet je gewoon meedoen. Als je afwacht zal je worden ingehaald.

Momenteel ben ik bezig om testgnunetd.c te poorten naar mysql en daarna naar Windows. Testgnunetd.c zal de basis voor online versie worden. Met foondump maak je een batch dump en met de online versie kan je een eigen foonbase gaan maken en onderling synchroniseren. Stel jij vind een optimalisatie in de foonbase door records te verwijderen en/of aan te vullen dan maak je een SQL script en deze wordt door de peerservers automatisch uitgevoerd.

Dus het CD-foon-zoekprogramma ziet op een of andere manier kans om onderscheid te maken tussen een enkele vermelding voor Funprice Computers in de plaats Arnhem en een tweede, identieke, vermelding voor het postcodegebied 6811.

Mijn vraag zou zijn: op basis van wat voor informatie kan de CD-foongids dat doen en kan Foondump daar dan niet ook op ziften?

Postcode, plaats en straat hebben allemaal x,y coordinaten. Deze heb ik al gedumpt van de cdfoon. Je kan gemakkelijk op de dichts bijzijnde vestiging sorteren. Wel zal de route informatie nog uitgezocht moeten worden van de cdfoon.

De vriendelijke groet Jan Marco

alkema_jm · 12 november 2004 om 16:07

Hoi Weerman, Ter Info,

De dubbele records worden er op de volgende manier uitgehaald:

"Het zit net iets anders. Het is deels het dump-proces en deels de opbouw van de gids.

Ze doen het als volgt:

een vermelding kan in meerdere plaatsen voorkomen.
een vermelding in een plaats kan onder meerdere trefwoorden voorkomen
wordt gekozen door de abonnee
wordt automatisch gedaan door alle losse woorden van de naam te splitsen en veel voorkomende tussenvoegsels e.d. eruit te filteren. Dat kan goed uit de hand lopen, bijvoorbeeld de entry “Hankamp Gert Jan en Thije Linda Ten” komt dus onder 6 trefwoorden voor (alleen en sneuvelt in het filter).

De enige manier van dumpen is door plaatsen af te lopen, vervolgens de trefwoorden en dan de vermeldingen.

Stel dat Gert Jan en Linda besloten hebben dat ze zowel in Aalsmeer als in Lutjebroek vermeld willen worden, komt het dump proces dit stel dus in 2 plaatsen x 6 trefwoorden = 12 keer tegen.

Binnen een plaats filtert Foondump de dubbele vermeldingen er weer uit door alleen entries die beginnen met hetzelfde woord als het trefwoord, in acht te nemen. In dit voorbeeld wordt de vermelding dus alleen gedumpt bij het trefwoord ‘Hankamp’.

NB. dit werkt niet perfect. Een vermelding van broer en zus zoals ‘Jansen Jan en Jansen Mariska’ wordt twee keer gedumpt door Foondump. Omdat een slimmer algoritme het dumpen ernstig zou vertragen heb ik besloten hiermee te leven."

Alleen de info records van de eerste entry worden gedumpt bij pink.

In pink zit een check om dubbele records eruit te halen, omdat entries steeds terugkomen (die check met die md5 hashcode).

Deze check vergelijkt echter alleen de subscriber records. De aanname is dat als subscriber records gelijk zijn, de info records dat ook zijn. Dat is niet altijd een juiste aanname.

Wanneer 2 subscriber records precies hetzelfde zijn maar verschillende info records hebben wordt het info record voor het tweede subscriber record weggegooid. Het komt niet vaak voor maar wel af en toe.

De vriendelijke groet Jan Marco

P.S. Test case: Dynabyte, pink: Ik zie geen info records bij Assen staan behalve “13916749v”. Ik zie de info records wel in de cdfoon pink Assen dynabyte. Zou volgens cdfoon pink het volgende moeten zijn:

Klik hier voor onze @vertentie op internet!

Grootste computerwinkel van Nederland met vestigingen door heel Nederland. Het breedste assortiment hard- en software met bekende merken zoals Canon, HP, Microsoft, Sony en Headstart. 0592 330300 Koopmansplein 16 9401 EL Assen 0591 648285 Hoofdstraat 149 7811 EM Emmen 0900-DYNABYTE(0900-39622983 EUR 0.15 p/m.) www.dynabyte.nl

Weerman · 12 november 2004 om 17:23

Zit je niet per ongeluk in de verkeerde dump te kijken?

[quote=“rgj”]Het was nog erger, alle info en phonenumber records waren verschoven. Bij subscriber record x hoorde info record x+1.

Let op dat alle met v4.10 gedumpte gidsen dus onjuiste gegevens in de pink_info en pink_phonenumbers tabel hebben!!!

forums.virtualconspiracy.com/foondump/viewtopic.php?p=454#454[/quote]

rgj · 12 november 2004 om 19:13

Zit je niet per ongeluk in de verkeerde dump te kijken?[/quote]

Nee, ik zie ook wat Jan Marco ziet.

Weerman · 12 november 2004 om 20:17

Jullie zien dit niet?

[code][C:\Foondump\CSV Pink]grep -i dynabyte.*assen pink_subscriber.csv
180264 DYNABYTE Koopmansplein 16 9401 EL Assen 0592 330300

[C:\Foondump\CSV Pink]grep -i 180264 pink_info.csv
180264 0 0 4 13814011
180264 0 1 0 ?
180264 0 2 3 5097152_010
180264 1 0 5 Grootste computerwinkel van Nederland
180264 2 0 5 met vestigingen door heel Nederland.
180264 3 0 5 Het breedste assortiment hard- en software met bekende
180264 4 0 5 merken zoals Canon, HP, Microsoft, Sony en Headstart.
180264 5 0 5
180264 6 0 9 0592
180264 6 1 9 330300
180264 6 2 10 Koopmansplein
180264 6 3 13 16
180264 6 4 12 9401EL
180264 6 5 8 Assen
180264 7 0 9 0591
180264 7 1 9 648285
180264 7 2 10 Hoofdstraat
180264 7 3 13 149
180264 7 4 12 7811EM
180264 7 5 8 Emmen
180264 8 0 5 0900-DYNABYTE (0900-39622983 / EUR 0.15 p/m.)
180264 9 0 5 www.dynabyte.nl[/code]

rgj · 13 november 2004 om 07:56

[code]mysql> select i.* from pink_info i, pink_subscriber s where s.id = i.id and s.townname=‘Assen’ and s.fullname=‘Dynabyte’;
±-------±-------±------±-----±----------+
| id | lineno | recno | type | infovalue |
±-------±-------±------±-----±----------+
| 890171 | 0 | 0 | 4 | 13916749 |
| 890171 | 0 | 1 | 0 | |
±-------±-------±------±-----±----------+
2 rows in set (0.14 sec)

[/code]En mysql> select s.* from pink_info i, pink_subscriber s where s.id = i.id and i.infovalue='Grootste computerwinkel van Nederland';
Levert 31 Dynabyte winkels op, maar niet die in Assen.

Maar Weerman, ik zie bij jou in de eerste twee regels ook rommel!?